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SIMULATION HIGHER ORDER LANGUAGE 
REQUIREMENTS STUDY 



Section 1 

'introduction 

In most appliNcations , the use of higher order languages (HOLs) 
for software development is common. However, in a few areas the use 
of HOLs is rare. In general, sucri areas are characterized by stringent 
computer resources. HOLs have re.cently made sxibstantial inroads into 
these application areas. In the avionics software area, where size, 
speed, performance, and reliability of the software for the on-board 
computer have always been vitrxl, HOLs have been used with success. 
The B-1 offensive avionics software is writteli in JOVIAL J3B; the softwa 
for the F-I6 Fire Control Computer is 'xlso written in JOVIAL J3B. 
The real-time mission software for the Digital Avionics Information 
System (DAIS) and the Electronically Agile Radar (EAR) is being written 
in JOVIAL J73I. Portions of some fUght training simulators have 
been written in FORTRAN. ^ The experience with the use of HOLs in 
avionics projects as well as, some recent simulator projects indicates 
the use of HiDLs in real-tirr.e flight training simulators is feasible, 
piven that thi« is the ca.s«, an important question must be answered: 
which existing HOL, if any^ is most suitable -as a potential standard for 
developing real-time training sirnulator software? What modifications to. 
an existing language must be made to make it suitable? The.study 
described in ithis report defines simulator HOL (SHOL) requirements 
and analyzes! PL/I, FORTRAN, JOVIAL J3B , JOVIAL J73I, and PASCAL 
for 'suitability in meeting these requirements. 

j ' . ■ ' . * ' 

In determining HOL requirements 'for simulator programming,^ 

we' considered not only simulator needs but also work currently underway 

within DoD leading to the possible development of a coRimon high order 

programming language for embedded computer systems applications. 

Embedded computer systems. ar^ defined as systems^'*integral,to a 

larger military! system or weapon, including technical Aveapons systems, 

communications, comnfiand and control, avionics, simulation, test 

equipment^ training, and systems progrannming applications" [Fisher, 

197i)] . Clearly real-time flight training simulators fall within the class 

of embedded computer systems. . , 

The goal of the commoT> language effort is "the adoption of a very 
few (possibly only one) common programrmn^ languages to be used for 
th'e design, development, support, and marntenance of all digital compute 
software for embedded computer applications in the DoD" [Fisher, 19V6] 
This means that if the programming of flighb simulator s has unique 
characteristics not shared by other embedded computer applications and 
if these chai:acteristics imply that a SHOL must contain features not need 
in other embedded computer applications, then a' speciaj^-purpose 
simulator programming language will be justified untj^er the common 



programming language effort. Our approach to defining the required 
SHOL characteristics was designed^ to help decide how specialized 
simulation programming requirements really are. Given the high 
level DoD interest in minimizing the number of distinct programming 
languages, it is reasonable to assume that developing a new or 
modified language for simulator programming will be possible only 
if the need can be clearly- demonstrated. 



^'Considering this background, the, main objectives of this study 



were : 



• to define simulator HOL requirements in a way that can 
be related to the DoD common language effort; 

: • to'determine which of PL/I, FORTRAN, JOVIAL J3B, 
JOVIAL J73I, and PASCAL is most suitable for use or , 
modification as a simulator programming language; 

to recomm*end methods for implementing and enforcing 
the use of a standard simulator HOL. 

The remainder of this report describes our findings and the methods we 
used in obtaining them. 
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Section 2 
OVERVIEW 



Ii;! this Section we discuss the general nature of our study, the 
methods we employed to~ reach the conclusions rep)orted later, and 
give an overview of the remainder of the report. , 

Although the rhain objective of our study was to define simulator 
HOL requirements, a subsidiary objective was tO/ develop a general^ . 
approach for determining HOL requirements in a given application area 
and to then apply this, approach to the simulator area. The general 
approach we have devised focuses' pn three sources of language require- 
ments: 

• the programming environment , i. e. , factors pertaining to 
the development and maintenance environment of a 
particular application area, e, g. , 

o long or short program lifetirhe 

' • programmer background * 

• / . potential for program portability , 

• compiler efficiency requirements 

• functional requirements ; i.e., the programs developed • 

for a given application. These programs can be subclassified 
into two groups: 

progr arris that perform application functions; and 

• programs that assist in developing other programs, 
e. g. I" data file generation programs, debugging 
prPRrams, etc. 

- / . ' ^ ' * 

• lanp;uage design principles , i.e., -accepted and ernerging 
program development-methodologies and principles, -> 
independent of sLny particular application area and i-eflecting 
current thinking about what the properties of a ''good" 
programming languagfe are,, e* g. , 

• linguistic simplicity and uniformity ^ . 
m' support for structured programming 

• support for modular programming^ 
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The fir St portion of our study^^-as devoted to describing the sirnu- 
lator programming environment and simulator functional requirements. 
The Link Division of the Singer Company, as subcontractor to SofTech, 
was our principal source of information on simulator requirements. 
Link provided simulator programs and documentation for our analysis. 
They later reviewed our characterization of the environmental and 
functional requirements to confirm that they accurately reflected simu- 
lator needs. Although SofTech was responsible for the language analysis, 
Link was responsible for ensuring that our language conclusions were 
based on an accurate understanding of simulator requirements. 

Our findings regarding environmental requirements are ' 
described in Section 4; functional requirements are described in 
Section 5. To guide and support our analysis of functional require- 
ments, a benchmark model of a generic flight training simulator was 
developed. The benchmark model is a key part of our analysis because 
it represents the entire, set of programming tasks relevant to simulator 
development. Our analysis cff language requirements is keyed to this 
-model. Because of the importance of the model, it is discussed 
separately in Section 3. 

Our analysis of the simulator programniing environment, simu - 
lator program functional characteristics, and language design principles 
resulted in the specification of simulator HOL requirements given in 
Section 6. This specification of requirements serves as the definitive 
basis for evaluating how well existing programming languages could" 
serve in programming simulators. '■ It serves to document the key 
implications of our study of programming requirements concisely and 
rigorously. ^ 

.To facilitate comparison of si: mlator requirements with the 
proposed Common Language requirements, the requirements specifica- 
tion in Section 6 has a structure similar to that of the IRONMAN 
[U.S. DoD, 1977]. The IRONMAN requirements specification is the 
latest in a series of evolutionary language requirements documents 
issued as part of the Common Language effort. It is the require- . 
fnents specification being used to direct preliminary language design - 
efforts completed in Februrary 1978. The IRONMAN specification 
is the most recent specification of language requirements and thereby 
most s.uitably represents the current DoD position on embedded 
computer application requirements. 

r Based on our modification of the IRONMAN requirements specifi- 
cation, we selected a set of language features satisfying the requirements 
using a computerized database of 2267 language features [SofTech, 1977]. 
This list of features was also used to describe each of the programming 
. languages being^ evaluated, namely, PL/1, FORTRAN, JOVIAL J3B. 
JOVIAL J7'3I, and PASCAL. By analyzing which features satisfied the 
SHOL requirements specification and were present or absent in each of 
these languages, we decided how well each language satisfied the SHOL 
requirements. 

4 
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Section 6 contains both the *SHOL requirements specification and 
our evaluations ol the candidate languages with respect to the require- 
ments. The value of combining the requirements specification and 
the evaluations in this way is twofold: 

• a particular evaluation is most understandable when 
preceded by a statement of the requirement under 
consideration. 

9 a requirement can frequently be understood more readily 

by reading the discussion of how well the various languages 
J meet that requirement. 

An.overall summary of how well each language satisfied the requirements 
is given at the end of Section 6. PL/I and JOVIAL J3B were judged to be 
the languages best satisifying the requirements without modifications, 
although only FORTRAN is clearly the lease suitable language. 

Since all the languages failed to satisfy some of. the .simulator 
language requir ementg, we considered what language modifications 
would make them significantly more useful as simulator programming 
languages. To assist in this analysis, we divided the simulator require- 
ments into two classes: those considered essential both to accomplish 
all necessary simulator, programming functions and to meet the more 
general SHOL design goals of reliability and maintainability, and those 
considered beneficial in a new ^ language but not of sufficient importance 
that it is. essential to modify a language to satisfy them. In essence, 
if the non-mandatory requirements can be satisfied with a minor 
laYiguage modification, then the modification should be made, but if the 
modification is complex or changes the fundamental syntactic and - 
semantic constraints of a language, then its impact as a change outweighs 
its benefits to simulator programming^ For example, changing PASCAL' 
semicolons to statement terminators instead of separators would be a 
non-mandatory modification. 

^ Modification issues are discussed further in Section 7, and the 

modifications selected for each language are presented in Section 8. 
Based^on the extent of the modifications and the usefulness of the modi- 
fied language, we selected PL/l as the language most suitable for 
modifications.. This decision is discussed at the end of Section 8. 

As the final part of our study, we addressed how' to support the 
use of a standard SHOL. Section 9 discusses these issues, which 
include language design and implementation approaches as well as 
recommendation? for introducing^and establishing SHOL usage. 



1 ' Sectio.n»3 , 

THE SIMULATOR BENCHMARK 

t. 

A significant part of this study involved familiarization with the 
programming requirements of. flight simulators. To assist in this 
analysis a benchmark simulator problem was developed. This bench- 
mark models a generic flight training simulator, i.e. , it does not 
describe the op.eratio.n of a particular simulator, but rather incorporates 
the characteristics typical of simulators in general. The benchmark 
served.two major purposes in the study: 

• It provided an overall framework for the entire analysis of 
simulator functional requirements. 

• It prx>vided a frame of reference for presenting results. 
The material describing language requirements (in Sections 
4, 5, and 6) is cross-referenced to components of the 
benchmark model, allowing the reader to: 

a) Determine the simulator area(s) from which a 
particular requirement derives. 

b) Determine those requirements which derive from a 
particular sim:ilator area. 

Development of the Benchmark 

The basis of the benchrrark development was our analysis of. 
simulator p:-ograms and desig: . documents. The purpose of this effort 
was to determine the types of processing required when programming 
flight training simulators. A mSjor concern was to determine what 
functions must be performed rather than how they are currently imple- 
mented, since the goal of the SHOL is to permit programming the 
required functions rather than duplicating the programming techniques 
which are currently used to realise these functions. Thus, the effort 
had.to go beyond a simple investigation of the programming techniques 
currently employed. For this reason, the benchmark developed is a 
functional , rather than an operational , representation of a generic 
flight simulator. 

The primary inputs to the programming analysis effort were 
provided by the Link Division of the Singer Company, serving as a sub- 
contractor to SofTech. At the start of the study. Link presented a two 
day orientation briefing to SofTech personnel. The briefing included 
presentations by representatives of each of th^ major simulation areas 
as well as discussions of the overall application. The briefing provided 
a general framework for the subsequent programming analysis and also 
highlighted issues of particular concern to simulator personnel regarding 
the use of an HOL. 
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Subsequently, Link provided extensive documentation to.SofTech 
for study* The materials studied were: 

• UPT (Undergraduate Pilot Trainer)- - 26 volumes of design 
documentation plus listings, representing the entire system 

• F-14 ~ documentation and listings from flight and navigation 
subsystems " ' , 

© 214A - dp^cumentation and listings from the visual (camera/ 
model board) subsystem 

• SMS (Shuttle Missio;n Simulator) - documentation from the 
visual (digital image generation) subsystem 

• other tactics programs - listings (names of systems were 
not provided to SofTech) 

The fact that a single complete system (the UPT) was studied was 
important to the effort, as it guaranteed that no major functional aspect 
of simulator programming was overlooked.. This would not necessarily 
be the case if only isolated programs selected as '^represe^ntative'^ y/ere ' 
studied; the selection of representative programs would have required 
knowledge that was npt available prior to the analysis effort. Certain 
areas not included in" the UPT material were covered by the other 
simulator documentation. These werie: 

• /camera/model board visual (The UPT visual system was 

done by a subcontractor to Link, vRedifon, and was thus 
not included in the UPT documentation) 

• computer image generation-visual 

• ' tactics 

4 

Other material v/ets studied ^yhich duplicated UPT areas, to help ensure 
that the a'nalys'ls concentrated on the functions to be performed, rather 
than on a single approach to programming those functions. . 

Other important advantages to the study of actual simulator 
programs were: 

m It was possible to make judgements concerning the degree of 
efficiency actually required of the object code which the-SHOL 
tranbiator must generate. That is, if a certain algorithm 
not displaying the maximum efficiency is observed to be 
adequate, , it is possible to conclude that comparable code 
generated by an HOL compiler will also be adequate. 



J '■ ' m It was possible to isolate certain areas of potential 

inefficiency^ which occur frequently and which it is thus 
particularly important that an HOL compiler avoid. 

• Areas where us^ of an HOL would have a particularly 
beneficial effect on program readability could be observed 
and highlighted. 

As the program analysis proceeded, informal written observations 
on the programruing requirements of the various areas were prepared . 
and submitted to Link for comment. This helped guarantee that -no 
erroneous conclusions were reached. Similarly, Link reviewed the 
benchmark model as it was developed,s as did the Air Force. Based 
on comments received, the model was reworked. Thus model develop- 
ment was an iterative process, with each iteration reviewed by 
simulator experts. 

Presentation of the Benchmark — 

The benchmark model, contained in Appendix A, employs 
SofTech's Structured Analysis and Design Technique (SADT@)[R^ss, 1977]. 
SADT has been found to be a valuable technique for communication^ 
between individuals performing analysis in a given problem area and 
individuals who are experts inthat-^rea. The sirriulator benchmark ' 
model assists in communicating the findings of the SHOL investigation 
to simulator experts. 

Th(e' model consists of a set of diagrams which form a hier- 
archical decomposition of a generic flight simulator. Th^ diagrams 
are/made. up of boxes representing activities (functions performed), .and 
arrows representing ^data which is an input or an output of these functions. 
Each diagram is itself an expansion of an activity bfex. which appears as 
one of the boxes on a preceding higher level diagram (its parent ). The 
arrows entering and- exiting a diagram exactly match t|ie arrows 
attached to the box on the parent diagram. Figure^- rAshoAvs a sample 
SADT diagrapn and explains the notation used. 

The first diagram of the benchmark model, node A-0, contains 
a single box representing ill functions which must be prograrr^ed in' 
developing a flight simulator. The decomposition of this diagram 
appears in the second diagram of the model, node AO, which consists 
of three activities: 

• build simulator 

• test simulator ' , - 

• simulate 



X 



\ 



The diagram shows that the specification of the aircraft operation, and 
performance requirements which must be met by the simulator, control 
the building and testing activities. It also shows that building and ' 
testing are an iterative process* The "simulate" box shows the student 
actions as an input, the simulated aircraft reactions as an output, and 
the instructor inputs as a control of the activity. An additional output 
of this activity is the ijpiormation on student actions which is displayed 
to the instructor. 

. Subsequent diagrams further decompose these activities'. In 
particular, diagram^Al decompo^ses box 1, diagram A2 decomposes 
box 2, and diagram A3 decomposes box 3. The remaining diagrams ' 
further .decompose boxes of diagram A3, "simulate, " which is the 
major part of the model, particularly box 3 of A3, "model aircraft 
functions. " 
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Section 4 

PROGRAMMING ENVIRONMENT OBSERVATIONS ' 

' Part of our general approach to defining HOL requiijements in a 
given application area is to evaluate the effects of the environment 
in which prog/ams are developed and maintained. Environniental 
factors discussed in this Section are: , • * ^ 

• program development methods (groups, vs. individuals) 

• prograummer background and experience 
^ compilation, size and speed requirements 

• -object code size and speed requirements 

• program lifetime and stability 

• program reusability potential 

• program portability potential 

Each of these factors has some influence on v^^hat language features are 
most suitable for simulator programming: In subsequent subsections, 
we discuss the environmental factors for simulator programming and 
their relation to language features/ The information presented here on 
the simulator programming environment was obtained primarily from 
discus'sions with simulator personnel. The findings presented in this 
and the next Section were used in defining the detailed language 
reqvii rernents specifi^ed in Section 6. 

4.1 i Program Development Methods 

Simulators are very large systems programmed by many 
programmers rather than by. a single individual. Coordination,between 
these programmer's should be supported by the SHOL. In particular, 
programmers must be able to interface their programs with those 
produced by others and must be able to. access system data in a consis- 
tent manner. The SHOL should diagnose conflicts in these areas. It 
might also J5e desirable to control (or at least be able to detect) access 
to data by a program which should not read and/or alter that data. 
Section 5.1.1 discusses the methods currently used to support data 
coordination in simulator development. 

The large number of programmers implies a requirement for 
separate compilation of programs, i.e. . individual programmers must 
be able to separately compile, modify, and test their programs and 



then integrate them to form the complete systeni. Some support for 
the integration process and for system level testing is also essential. 

Use of system data by large numbers of programmers requires 
lib raries of data definitions and subroutine declarations. These 
facilitate consistent access to global data and allow inconsistent 
assumptionsjabout forms of data structures and parameters to be . 
detected at compile time. Such inconsistencies can easily arise when 
groups of programmers are involved, 

4. 2 Programmer Experience 

Simulator programs are produced primarily byundividuals 
' trained in an engineering specialty rather than in computer science. 
This results in a programmer prefe^nce for language notation. which 
reflects the engineering notatioa usc^d in the simulator design descrip- 
tions. An example of this" is'^the use of conditional expressions in 
|5rogram documentation, as discussed in Section 5.4.1,1. Inclusion oi^ 
this feature in a SHOL is primarily justified by this documentation 
practice. 

• • ^ ' . ' V ' " 

Another consideration based on programmer experience/is a 
strong preference for fixed point as opposed Vo floating point, (The 
re^^sons for 'this are discussed in Section 5, 2, 2, 1 , ) A SHOL should 
provide programmer control of real number representations , Much. ^ 
programmer, concern about the use of floating point comes from fear of 
loss of control over significance in computations. Concern about the 
space required by certain real number representations is a-lsb apparent. 
The SHOL should provide access to the various representations available 
on the target computer. 

Most simulators are currently inriplemented in assembly language 
with occasional uses of FORTRAN. Most simulator programmers^'^have 
not been exposed to other languages, IiT selecting/designing a SHOL, 
consideration should be given to the problem of retraining prbgrannmers « 
in the language, especially in view of the large number of individuals 
involved. When a choice is to be made 'an>feng several language features 
satisfying a. particular functional requirem^ent, programmer background 
indicates that^the choice be made on tJie grounds of simplicity of use and 
similarity to commonly-used programming, languages. 

Another consideration, at least in the Link envirStiment, is the 
use of a Quality Assurance group to optimize the prograffis produced by 
the engineers.' This dictates a requirement fojr program understand- ' 
ability, to ensure -that changes made'by this group do not alter programs 
functionally. Language, features supporting understandability are 
discussednn Section 4, 5, 



4. :3 Compilation Size and Speed Requirements 

In simulator development, constraints on compiler performance 
are "imposed by the computer being used for compilation. Conventionally, 
compilation is done on the target' computer , i.e. , the computer on which 
the simulation programs will execute. Typically, these computers asre 
of moderate size^and speed. Examples of machines used are: 

' o ^ PDF 11/45 . 

• Honeywell 316, 516 , ' 

• Interdata 8/32 

• SEL 3250 

• Harris DC 6024/4 \ / 

This practice of compiling on the ta-rget machine would require that the 
SHOL be compilable on machines of this size; (Note that disk storage 
is available with all of the systems. ) Thisrms^triction would also dictate 
that the SHOL compiler be implemented in ajdng.uage supported on the 
target machine. Clearly, development of^^mpilers in each of the 
various target machine assembly languages would be costly. An' alter- 
native to this would be implementation of the SHOL compiler in the SHOL 
(bootstrapped). This would require that the SHOL contain thp capabilities 
required for the compiler implementation^ This would probably require 
no features hot also needed to produce the various offline simulation 
support programs, several of which are special -purpose compilers. 

Constraints on compiler size and speed might also affect the • 
amount of optimization performed by, the compiler. A language offering 
programmer -controlled optimization allows the programmer to limit 
the amount of opti-nization performed by the/^ompiler, thus increasing 
compiler speed and decreasing core requirements. The programmer 
will then perform optimization explicitly through appropriate use of the 
HOL. . ^ • 

The constraints described above could be avoided by use^of a 
single, larger-scale host computer for compilation. A dej>a:Tture of 
this sort from the current practice involves considerations which cannot 
be fully addressed here. Among these is the requirement for program 
modification in the^ field, discussed in Section 4.6. 

4. 4 Object Code Size, and Speed Requirements 

Object code size constraints are imposed by the available core 
oh the. target systerp. A typical simulator might occupy lOOK words of 
core -- 8QK for program and 20K for data. An additional constraint 
stems from>the requirement to deliver spare core. (Though core can 
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bemadded, it is desirable to keep costs down and to stay within the 
addressing capacity of the machine.) Simulator programs studied 
reflect a desire to conserve core (e, g, , packing of logicals, use of 
fixed point for large data tables 3vhen floating point would require double 
words), but not at the expx^nse of operating speed. 

Speed of obje^ct code execution is of primary importance in simu- 
lation. Clearly, the simulator must respond to pilot actions as quickly 
as the actual aircraft. Simultaneously with this realtime response, 
other functions, such as performance recording must occur. Not only is 
speed itself important but coordination of the various system components 
is vitaL Small discrepancies between the visual and motion systems, 
,,for example, are discernible to the pilot. 

Study of the simulator programs has verified the concern for 
time efficiency over- space efficiency. For example. Section 5,2.9.2 
discusses the use of inline subroutines to increase speed of execution. 
The ability to specify inline expansion- of subroutines (as opposed to 
calling the subroutine) allows the programmer to trade space for 
execution speed. The specification should be p^rt of the subroutine 
definition, and calls for both types should be written the same way. 
This facilitates changing the method used (i, e. , only one definition, not 
numerous calls, must be changed) when tuning for the best time-space 
balance, . ^ ^ . 

Another feature required to provide object code efficiency is 
programmer control over packing of data. This feature allows the 
programmer to choose between the space savings possible with 'packed 
data (e,g. , packed Boolean itenris) and the speed of accessing provided 
by unpadded data. . A choice of parallel or serial table allocation also 
^provides control over execution speed, since data can be arranged to 
support efficient accessing. 

- The need for. execution speed has dictated the need for multi:^ 
processing. More than one CPU (typically three or four) are required 
to obtain the desired performance. Multiprocessing requires that a 
SHOL support inter -CPU communication and sharing of data. Section 
5.4.2 discusses language features directly supporting multiprocessing. 
In addition, conditional compilation (Section 5.5,2) is useful in adapting 
programs to the CPU on ^yhich they will execute. It allows ^essentially 
the same program to operate on different CPUs. 

4*. 5 Program Lifetime and Stability 

In general, simulator programs have a long lifetime, since 
simulators can be used for years before becomi'ng obsolete. This 
^implies that the programs must be understood and modified by 
programmers who did not produce the original program or make previou 
modifications. A SHOL should assist in making program^N under stand - 
able so changes can be made quickly and correctly by programmers 
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unfamiliar with the program. Thus, program readability should be 
stressed over programming ease (which might be preferred for programs 
with a short lifetime). , 

Simiilator programs are fairly stable once they are put into use. 
Changes are most frequent in the tactics simulation programs, e. g. , 
the- programs emulating the onboard cot?aputer software. Frequently 
the simulator user (the customer) mak'e3 program modifications in the 
field. Modification by individuals not in>^olved in program creation and 
also hot primarily involved in simulation^. engineering disciplines demands 
progirim understandability and readability. 

Among the.kinds of language features that foster understandability 
are, for example, ^he :.catus, or enumeration, data type. Section 5.2.3 
presents several examples of the use of status data in programming 
simulator functions. Explicit data declarations are also important; 
The type of each -variable' should be stated explicitly (and in a readily- 
findable location in the program text). In addition, the ability to assign 
mnemonic names to constants (e.g. , the use of the name PI for the 
constant 3. 1415. . . ) enhances understandability. To prevent modifica- 
tion errors, such constants should be a distinct language entity, not just 
variables initialized to desired values. 

Error prevention and error detection features also help to reduce 
modification errors. Among the features facilitating error prevention 
and detection are strong typing and range declarations. Strong typing 
means that implicit type conversions are forbidden (e. g. , when assign- 
ing a value to a variable). Forbidding implicit type, conversions helps 
to flag errors when programs are modified. Similarly, range declara- 
tions, i.e. , the specification of the intended value range' of a variable, 
helps to prevent and detect errors. Range information is readily avail- 
able for simulator data, so a requirement for its specific inclusion in 
programs should not present a problem. 

Many of the language features dictated by general language 
design principles also contribute to program readability and modifiability 
For example, uniformity in language syntax, structured programming 
constructs, and simplicity of the language all make programs .easier to 
understand. A comment facility which is flexible and convenient to use 
also encourages production of understandable programs. 

The implications of onsite simulator program modification are 
twofold. If the modifications are made by patching, the SHOL compiler 
must provide listings of machine code representationSv. j6f programs and 
possibly other loading/relocation information! If , modification is dorle 
by recompilation, it is necessary that the^compiler operate on the target 
rpachine (see Section 4. 3) since the users would not necessarily have 
access to the host machine used by a cross-compiler. 
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4. 6 Program Reusability 

Program reusability (as opposed to program portability, which is 
discussed in Section 4.7) is concerned with the ability to reuse a program 
for different purposes for the same 'target computer family. An 
example of reusability is the generation of slightly different subroutines 
adapted to the different simulation capabilities of the cockpits in the 
Undcrgradiiate Pilot Trainer, simulator. ' .<^ ' " 

Features supporting reusability are essentially program genera -j^T 
tion features, i. e. , .they permit different versions of a program to be 
easily compiled. ^Conditional .compilation is an essential language 
feature for facilitating program reusability since reusable routines are' 
often too general purpose for efficient,, special purpose use. Conditional 
compilation is used, to remove unneeded generality from "such a routine, • 
Use of constant .names is a'nother way of adapting a program to different 
--configurations,^ These constant names can be used to specify configu- 

ration^dependent constants for reusable modules, 

.* * 

Neither conditional compilation nor the use of constant names 
permits onsite patches to programs as a means of adapting to new con- 
figurations (e, g, , if code has been conditionally dropped out, a patch 
ca^nnot access it). The use of patches to make the kinds of changes 
achievable throi;gh conditional compilation and use of constant names does 
not appear to be a significant practice in simrulator environments. Con- 
figuration changes often require recompilation/assembly because of 
their complexity, 

4. 7 Program Portability 

Program portability is concerned with the use of HOL source 
code for different target computers. There is greater need for port- 
ability in the simulator applications area than in most. Many program^ 
change very little from one simulator to the next; e*g, , the navigation 
and communications programs; simulation of radio stations does not. 
depend on the particular aircraft involved, A similar situation exists 
in the tactics area when simulating radar emitters and various types of 
weapons. Even in simulation areas more dependent on the'^-aerodynamics 
of the aircraft, portability is possible (e, g, , solving six degrees of 
freedom equations). Visual systems also have much the same proces- 
sing ifrom one system to the next (e, g* , probe and gantry control, 
altitude limit, visual effects, and cultural lighting controls). Such 
systems are seldom identical but have considerable processing in 
common, ^nce there is significant potential for portability in the 
simulator area, a SHOL should encourage development of portable 
programs. Indeed, this is one of the major advantages of using an HOL 
as opposed to assembly language,. 
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A truly portable program, of course, mugt not be target machine 
dependent. ''This goal is probably ^inrealizable for simulator systems as 
a whole, though it may be possible for some modules. However, 
machine-dependent code can be isolated, thus facilitating the changes 
required to transport the program. 

Machine dependency arises 4n several ways. Th^ most obvious 
is in the programrr\ing of functioaslwliich cannot be implemented in the 
HOL and must be implemented in^^s-sem^ly language. (Section 3. 7 \. 
di/^cusses these functions,, as required in simulator programming, ) 
Assembly language code should not'b^ intermingled with'HOL source 
code but should be encapsulated to ease its replacement.* The HOL 
should-probably requite that assembly code be used only in separate 
Assembly language subroutines. In the programs studied, most functions 
requiring assembly language occur in the monitor area, which might . 
well be an area where not too much pprtability <:an be attained due to 
the nature'of the functions required. : 

Another instance of'machine dependency is in programmer- 
specified ddta,^ packing. As indicated in Section.4. 4, this feature may 
be necessary to attain required time and space efficiency. It is 
definitely necessary to describe'l/O data, as discussed'in Section 
5.3. 4.1. I-. s^owever, it implies that^programs cannot'be transported 
to a machine with a different word length (at least; not to a smaller 
word length -- a larger Would simply' mean a waste of space). 

' Machine -dependent packing can be avoided by the us« of machine- 
independent pajcking attributes when control'over packing is needed just 
to make time-space tradeoffs. Packing attributes allow a programmer 
a choice of several degrees of packing {e. g. , unpacked, .medium, dense, 
tight) "without * requiring actual specification of bit positions. The packing 
attributes are then compiled appropriately for the^target computer. Data 
packing specified 4n this way does not hamper pcjritability. For I/O inter- 
face data, programmer specification of actual bit -level packing is 
necessary. Such specifications, which are machine-dependent, should 
be encapsulated in some way to support isolation and change. They 
might, for qxanfipre^ ' form a separate block or module of the global data- 
base; - - • . 

. A third source of machine dependency is programmer reliance 
on internal representations of data, e. g. , on the available range and* 
precision of real (fixed or floating) values for a particular target 
machine. A SHOL can assist portability by providing built-in operations 
to access implementation information, sueh as precision, radix, and 
exponent range of floating point values. A related language feature is 
the ability to specify machine configuration constants reflecting, for 
example, machine model, word sizes, etc. These can then. ]De used 
with conditional compilation to include/e^kclude machine-dependent code. 
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Section 5 

PROGRAM ANALYSIS OBSERVATIONS 



Part of our general approach to defining HOL requirements 
is to analyze how the functions to be programmed (as^ opposed to 
the. environment in which the programming takes place) affect the 
choice of language features. In this Section, we present our 
observations of simulator programming characteristics, as revealed 
by our study of simulator programs and discussions with simulator 
personnel. These; observations are part of the basis for the detailed 
language requirements specification given in Section 6. 

The simulator program functions and support program 
functions are described in Appendix A in the form of an SADT model. 
This model describes the functional components of a simulator and 
demonstrates our understanding of the simulator programming tasks. ' 
The remainder of this Section contains an analysis of how the 
functions to be programmed can be supported by various HOL 
fe.afe«tres. Our observations about the relation between simulator 
program functions and HOL features are cross-referenced to the 
' relevant parts of the SADT model (e.g. , a reference to "diagram 
A33" is to diagram A33 in Appendix A). Similarly, the model 
diagrams reference this Section of the report. For example, 





compute 

altitude 

limits 


J 


- — 





I 3.4.4., 5. 1. 1 

indicates that language requirements for "compute altitude limits" are 
discussed in Sections 5. 3. 4. 4 and 5. 5.1. 1. (Since the first digit of 
all section references is 5, this digit has been omitted from refers 
ences in the model. ) 

The analysis presented here is grouped by language area. 
The overall organization is: 

5. 1 Storage Management 

5.2 Data Types and Operations 

5. 3 ^ Aggregate Data Types 

5.4 Control Structures' 

5.5 Program Development Aids 
5^.6 I/O 

5.7 Machine Dependency 
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5. 1 Storage Management 



5,1.1 Global Data 

T,he primary storage management facility in the Link simulator 
is the ^datapooT, or system symbol dictionary. System data in 
this global, data base is used and/or updated as required by the simu- 
lation programs and by the cockpit and instructor station I/O 
processing. Diagrams Al, A3, and A33 illustrate datapool use. 
The datapool is similar to the JOVIAL COMPOOL. When programs 
reference datapool items, the address and type of the item is 
retrieved during assembly/compilation by the database system (see 
Section 5. 5). 

Datapool items are grouped into blocks. Each item's location 
is defined by its displacement within the block. This grouping 
facilitates relocation as well as allowing related items tc be grouped 

together. The data is broken up into 5 groups: 

/ 

private - cockpit dependent arithmetic 

private - cockpit independent/ ^ 

common - cockpit dependent logical 

common - cockpit dependent arithmetic 

common - cockpit independent 

'Common' and 'private' refer to the common and private memories. 
Cockpit dependent data is data of which there are several copies, 
one for each cockpit. To provide the user with access to the current 
cockpit data, the monitor (in the foreground dispatcher - diagram 
A312) initializes index registers to the base addresses of the data 
areas for that cockpit. In the UPT simulator, for example: 

register I = private - cockpit dependent arithmetic 
register K = common - cockpit dependent arithmetic 
register V = common - cockpit dependent logical 

The V register is a base register used for bit access instructions. 
Its contents here will actually be the same as the K register, 
since the common cockpit dependent logical and arithmetic data 
occupy the same data area. There are actually only two areas,, 
private and common. 

The programs which access the cockpit dependent data then 
can reference, for example: 

var , K 
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and obtain the value of *var' for the current cockpit. Ordinarily the 
index register will be dedicated to this purpose. However, the 
monitor also places the current values in global variables in 
case the user has to destroy the register values and must then 
restore them. The programmer need not actually know whether a 
particular item is-in common or private memory. Cockpit 
dependent variables are referenced by 

var, R 

and the, assembler (as modified by Link) substitutes either or 
'K' for 'R', based on inforr ^tion from the symbol dictionary. 

An HOL implementation might group the data into large 
tables, one for private data and one for common data, where each 
table has 4 entries, one for each cockpit. This table could then be - 
indexed by-the number of the active cockpit, so that 

;var(CKPT) 

would refer to the value of 'var' for the current cockpit. Such large 
tables, however, are rather unwieldy, and their elements would not 
all be simple items, but would sometimes be tables, arrays, etc. , 
leading to confusing subscripting. A much better representation 
would be something like the based block of PL/ 1 , i.e., a block 
based on a pointer variable established for the current cockpit. In 
any implementation, it would be desirable that the compiled code 
dedicate an index register to the block. (Typically, most statements 
in the program will reference data in one of the two blocks, so a 
good compiler should come close.) Statements explicitly dedicating 
an index register are also a possibility. 

The datapool as used by Link is an important tool for program 
reusability. The concept is used in each simulator, and many data 
items are the same in various simulators. Some such global data 
definition facility seems essential in a simulation HOL, however it 
be provided. It might l>€ desirable to restrict unauthorized accfess 
to global data more directly in this facility. Currently this can be 
done only indirectly through examination of the cross-reference 
listings . 

5.1.2 Local Data 

The simulator programs also make use of a temporary 
storage area (50 words in the 214A simulator, for example). These 
are shared by all the programs- Programs using^them cannot call 
one another, but this is not a problem. Generally programs are 
initiated from the monitor and retu.rn to it on completion without calling 
other programs ( diagram A31 2 illustrates task scheduling). Programs 
using the temporary storage area cannot be reentrant but reentrancy is 
required only in a few monitor subroutines. 
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Use of these temporary locations can make programs unreadable 
if the temporary storage names are not equated to more meaningful 
names. As an example of this problem, see Figures 5-1 and 5-2, 
which illustrate storage usage in display system processing (Box 4 
of diagram A35). A simulation HOL with a similar local storage 
strategy would have to provide some means of assigning meaningful 
names'to these locations in the various programs which use them. 
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5. 1.3 OWN Data 



OWN data is data local to a subroutine whose lvalue must be 
retained between invocations of the subroutine. Some uses of OWN 
data were observed in the programs' s.tudied. For example, the 
214A program which verifies data on the modelboard contour map 
(Box 1 of diagram A3353) retains location information between calls. 
Another ,example^is^ the Monitor TTY output driver, which must extract 
a buffer address and character. count from the parameter table 
on the first invocation, then maintain them by incrementing the 
address and dec rementing the count through subsequent invocations. 
A^ third example is the timer data (fire and overheat timers, 
indicated by the two-way output of Box 1 of diagram A33 1 35 , and 
icing timbers. Box 2 of the same diagram) used in the Miscellaneous 
Acces sories area. These time r s are used to keep track of the time . 
since the indicated p-^-oblem (e. g. , engine overlieat) was initiated 
so warnings, ^tc. ^ can be turned on after the appropriate interval. 

'5.1.4 Overlay Programs 

Overlay programs are used in several instances in the UPT 
simulator. For example, system initialization (Box 1 of diagram - 
A31) makes use of programs that are replaced in core after 
initialization. Overlays are also called in as required to process 
debugging and display handling functions . Some offline programs 
(e.g. , Math Model Test, ^ox 2 of diagram A2) are also organized 
in overlays.' 

■ • ' X 
Ordinarily overlay handling is an operating system (OS) function 
(of course the OS should be implementable in the selected HOL) but " 
in some machines the program must call the OS to bring in overlays; 
in' others, it can be effected automatically. If the program has to 
request overlays, the language must make this possible. To be 
usable in real-time applications, overlay handling must be 
efficiently implemented.. 

5. 2 Data Types and Operations 

5.2.1 Integer Data Type 

The programs studied show few uses of integers to represent 
actual simulator numeric data. Some uses were observed in the 
Miscellaneous Accessories area (diagram A33135) for fire, over- 
heat, and ice timers. Another use was observed in a weapon 
jettison program (Box 2 of A334). In general, however, most 
integer variables are used ior loop indices, Booleans, enumeration 
types, array indices, etc. The use to represent Boolean and 
enumeration values would disappear in a language that supported 
these data types directly. The remaining uses are not peculiar to 
simulators, (array indices, loop indices, etc.) but are found in almost 
any use of a language. 
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5.2.2 REAL Data Type ' ' ; 

J REAL data^s used throughoiTriTi^s^irnuiator for numeric 
values. Areas in which mathematical proc>essin£ is particularly 
heavy are Aerodynamics (diagram A3312), Visu^ (diagram A335), 
and Tactics'(diagram A334) modelling and thte offline Map. Plate 
Compiler (Box 5 of diagram A35). Most aircraft data (speed, roll, 
pitch, yaw, altitude, drag, etc.) is REAL dita. 

f 

5. 2. 2. 1 Fixed Point vs. Floating Point j| 

Both fixed and floating point -are used to represent REAL 
values. Link has indicated that fixed point is always selected 
unless contract requirements specify- floating point. (When 
FORTRAN is used to program a simulator, however^ floating' 
point is used. No atternpts at fixed point arithmetic with FORTRAN- 
integers have been noticed.) This preference fo^r fixed point comes 
partly from a desire to continue using the ^same data definitions, 
scaling, etc. used on previous simulators. Of course, once floating 
point is established, the new definitions could be reused. Other ^ 
considerations are the programmers' unfamiliarity with floating 
point and concern about loss of control ove r'-signi^icince in computa- 
tions. A third problem is that floating point is sometimes slower 
than fixed point (see [Babel, 1974]). Another paper [Goldiez, 1976] 
compares the relative speed of assembly language and FORTRAN pro 
grams; the FORTRAN programs took almost threei times as long. Th 
autfiors blame this discrepancy at least partially on the fact that the 
FORTRAN versions Used floating point while the assembly language 
versions used fixed point. 

The UPT simulator, one of the systems studied, uses * 
primarily floating point. On the UPT computer, the Harris DC 
6024M, floating point is all double word, with 39 bits of mantissa. 
In the 214A simulator, also studied, all arithmetic data used is fixed 
point. Much of the data in this simulator is two-word (i. ^. . 32 bit) 
fixed point. As two-word arithmetic is not Supported by the instruc- 
tion set, handling such data takes a lot of code. For example, 
subtracting one &«*Cjh value from another requires five instructions. 
Addition, if it is necessary to test for overflow, takes nine 
instructions. A high-level language which supported such a data 
type would result in much c'learer programs. Certainly, support 
of l6-bit fixed point only is not adequate. 

Reasons for the various scale factors Used for fixed point 
data are not 'always''clear . since the range of data items is not , . 
always apparent. Presumably sc'ale^ factor s are selected to allow 
retention of maximum significance during calculations. In all . 
instances where the units> represented by fractional values are 
-^apparent, the step size is a power of two. Much rescaling occurs 
durip^ calculations. Some uses of fixed point fractions oc<;ur when 
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integer data is being used, resulting in some loss of efficiency). 
For example, the code used in the 2,\4A simulator to multiply an 
integer value of 1, 2, 3, or 4 in RO by a constant 3 is: 

MUL #3B2,R0 ^ constant 3 scaled with 2 integer, 

13 fractional bits 

' ASHC #3, RO shift register pair left 3 to get 

' result in RO 

I. 

Multiplying by an integer 3 would have given the desired result in 
Rl in one step. If it had to be in RO, a move instruction, more 
efficient than a double shift, could then be used. Presumably this 
sort of thing is due to programmer habit and illustrates that some 
inefficiency can be tolerated in some fixed point computations. 

Several instances of fixed point- data occur in the UPT 
simulator. For example , . latitude and longitude are often expressed 
in BAMs (Binary Angular Measurement), or degrees/360. Some- 
times BAMs are represented in double word fixed point, e. g. , in 
the Navigation Environment area (diagram A332, Box 2 outputs). 
The documentation (UPT Product Specification, Vol. 1, Navigation 
Environment, p. 31) describes the reason: 

y "Since Lat and Long are defined in BAMs (Deg. /360) 
the 23rd bit in the single word is equivalent to 7. 82 ft 
v/hich is not enough resolution to maintain required 
accuracy. The 48th bit in the double word will be 
equivalent to 4, 7 x 10'^ ft. " 

The UPT also uses one-word fixed point in certain tables to 
save space as compared to the two words required by floating point. 
This occurs, for example, in the LFI (linear function interpolator) 
routines, which are described in more detail in Section 5. 3. 4. The 
LFI subroutines access a table of values in fixed point form. Once 
the correct value is found, it is converted to floating point before 
being returned. The reason for having the table in fixed point form 
is economy of space, since the fixed point values take only one word 
while two are required for floating point. The precision allowed by 
the single word is adequate for the values. The breakpoint table, 
used in the LFI search routines, contains floating point values. The 
breakpoints require greater precision. In the case of a two or three 
variable LFI, of course, the value table is much larger than the 
breakpoint table, so there is mor<i motivation to save space. (In 
the 214A visual system, which is' ail fixed point, the value tables 
are ?l11 single precision; the breakpoint ta.4es are sometimes single 
and sometimes double precision. Altitude breakpoints, for example, 
are doublie precision.) 



Fixed point values are also used in the display system 
(diagram A35). These are generally values that appear in large 
tables or disk files (e. g. , saved track data, Box 6 of diagram A35;). 
Fixed point is apparently use'5 to ^ave space over the two words 
required by floating point. ^ - 

5. '2. 2.2 Operations on REAL Dgtta . • " 

The standard mathematical operations. ( + , / are of 
course required. OtK:€kr operations, peiiformed by macros (inline 
functions) or by subroutines, are described in subsequent subsections 

5.2.2.2.1 Trigonometric Functions 

The functions used are SIN, COS, and ARCTAN. The map 
plate compiler (Box 5 of diagram A35) uses secants and cosecants, 
but since these are simply inverses of COS and SIN, no separate 
functions are used. The F-14A and 214A simulators include a single 
routine to compute both SIN and COS, thus saving time when both are 
required. The UPT has only the two separate routines. ^ 

' In the UPT simulator, the routines'use fixed point (BAMs) i 
for the angles and floating point for the functional values. Some 
routines that call them, e.g. , Aerodynamics (diagram A33 12) , 
maintain angles in floating point and must convert to BAMs to use 
them. Calls to the SIN and COS routines are preceded by float-to- 
fixed conversions, and calls to the ARCTAN routine are followed by 
f:xed-to-float conversions. 

5. 2. 2. 2. 2 LFIs 

Linear Function Interpolation is the calculation of a functional 
value by linear interpolation of its arguments in a predefined table of 
arguments and associated values. Two routines are used. The 
Vsearch* routine looks up the argument in the predefined argument 
(or breakpoint) list, obtaining the interpolant. The Value^ routine, 
with this interpolant as a parameter, computes the function value. 
The data structures used are discussed in Section 5. 3. 4. 

5. 2, 2. 2. 3 Limit Functions 

A common operation in the programs studied is a limit 
operation of the form: , ^ 

MAX (MIN( expression, upper bound), lower bound) 

e. g. , 

MAX(MIN(TEMP02 512. , 400.), -400.) 

or 

MAX (MIN(. 95238 (. 525 - HAIFLP) , 999) , 0.) 
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This is frequently written in the documentation in notation of the 
form: 



[.'95238^^. 525 - HAIFLP)] * 

0 • ' 

This function arises from a need to limit a value to an acceptable 
range/ frequently for output to analog hardware. It is particularly 
prevalent in the Aerodynamics (diagram A3312), Flight Controls 
(diagram A33 1 , Box 1), Hydraulic System (diagram A33133), and 
Navigation Radios (diagram A3323) areas. 

5. 2. 3 Status Data Types 

There are numerous instances in the simulation programs 
studied where a status (i.e. , enumeration),^ data type would enhance 
program readability. Status types would be useful for flags, for 
table and array indices , and for CASE alternative selectors (see 
also Section 5. 4. 1. 2). 

5. 2. 3. 1 Status Data as Flags 

Exainples of flags that could be represented by status types 
occur in the monitor area (diagram A31), in the demo/record/ 
playback area (Box 1 of A35), in the instructor area (Box 2 of A35), 
and the visual area (diagram A335). In the monitor area, flags are 
used to synchronize the various processors and to coordinate I/O, 
the CPU number and cockpit number used by the foreground task 
dispatcher (diagram A3 12), etc. In the derno/ record/playback area, 
flags are used to avoid playing a demo which is currently being 
recorded. In the instructor , area, stains variables would be useful 
to describe many of the initial condition settings', e.g. , day-dusk- 
night. In the visual area, subroutines are used with integer 
parameters indicating X, Y, or Z values are to be processed. The 
X, Y, Z enumeration type would enhance readability here also. 

5. 2. 3. 2 Status Data to Index Tables and Arrays 

Throughout the simulators examined, readability would be ^ 
greatly enhanced by grouping related data items into tables and 
arrays, even when the resulting structure will have only two or three 
entries. In such cases, an enumeration or status type is the logical 
choice to index the structure. Consider, for example, the set of 
items connected with the DME dial (Navigation Radios, diagram 
A3323, Box 3): ^ 

NDMUNT - DME units wheel 
NDMTEN - DME tens wheel- 

NDMHND - DME hundreds wheel ^ 
NDUNTX - DME units output x 
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NDTENX - DME tens output x 

NDHNDX - DME hundreds output x 

NDUNTY - DME units output y • . * 

NDTENY - DME tens output y 

NDHNDY - DME hundreds output y ' 

NDUNTl - DME linits wheel previous pass ■ 

NDTENl - DME tens wheel previous pass 

NDHNDl - DME hundreds wheel previous pass 

which could be represented by a 3-entry table (perhaps indexed by 
an enumeration type UNITS, TENS. .HUNDREDS): 

TABLE DMEDIAL (UNITS:HUNDREDS): 
. BEGIN 

ITEM DMWHEEL wheel value' 
ITEM DMOUTX output x 

ITEM DMOUTY output y 

ITEM DMWHEELl previous pass wheel value 
'* END 

Then, for example, the item currently called NDMUNT. would be 
referred to as DMWHEEL(UNITS)' Similarly, engine data^ (diagram 
A3313. Box 4). wing d^-.ta (diagram A3312'). etc.. could be^ 
organized in tables indexed by LEFT and RIGHT, or nose position 
in a table indexed by (UP, DOWN, CENTER). 

-Many flight data items are actually vec.tors of X. Y, and 
Z values. These are all represented by sets of three variables, e. g 

VXGMI, VYGMI, VZGMI 

or , 

VXPFB, VYPFB, VZPFB 

These would be best represented in an HOL using 3-elemcnt arrays, 
which could be indexed with an enumeration type using the identifiers 
X, Y. and Z, e. g.,, • 

VGm(X). VGMI(Y). VGMI(Z) 

or ^ 

VPFB(X), VPFB(Y). VPFB(Z) 



Similarly, there are numerous sets of values for roll, pitch, and 
heading, e. g. , 

VCPHI, VCPSI, VCTHTA 

which might be represented by 3-eiement arrays indexed by PHI, 
PSI, and THETA. 

5. 2. 3, 3 Status Data as CASE Alternatives 

, In the programs studied, there are numerous instances of 
CASE-like, control structures. In some of these the various case$ 
could be rnost understandably represented by status or enumeration 
type values. For example', one subroutine in demo/record/playback 
(Box 1 of diagram A35) has as a parameter an integer indicating 
the type of processing to be done: 

0 = disk read initialization data _ 

1 - disk read demo data 

2 = unpack disk data 

3 = playback 

4 - flyout 

Clearly mnemonic values would be more understandable than integers 
as parameters. 

Other examples of CASE alternatives best represented by 
enumeration types occur in the monitor area (diagram A31). These 
include the function specifications for the intercomputer communi- 
cations and background scheduling routines, and the I/O device 
selection for the input/output control coordinator. 

5.2.4. B it Data Type 

Most occurrences of bit data in the simulators studied corres- 
pond. more logically to the set data type discussed in Section 5. 3. 1. 
The major use of bit data is in machine- or device-dependent code. 

Instances of bit operations (bit insertion and extraction) 
could generally be avoided through the use of programmer-defined 
tables to access the desired, bits. These are discussed in 
Section 5.3.4. Some such instances may be rather forced, however. 
An example of this occurs in the Math Model Test program (diagram 
A2) of the UPT simulator in the part of the program which formats 
instructions for the trace, translating them from binary to xinemonic 
form. The UPT computer has a very complicated instruction format 
for this purpose. For example, register (specifications are part of 
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the opcode mnemonic rather than operand fields. Thus there are 42 ^. 
ADD opcodes-, for instance. This translation program involves a 
main routine and 46 subroutines as well as three tables of opcodes. 
Processing is^roughly as follows: 

a. Based on the first six bits of the opcode, .one of 
the three tables is selected, for prefix - 00g„ 
77g, or 'other'. 

b. Within the selected table, an entry is chosen by index- 
ing by the first six bits of the opcode for the ^other' 
table, and by the second six bits for the OOg and 77g 
tables, 

f 

c. The table entry consists of two words, containing: 



opcode mnetnonic 


sub 

no. 


sub 

no. 


sub 

no. 



The (possibly temporary) opcode mnemonic is obtained 
frorn the first word. The second word contains three 
8-bit numbers. between 0 and 46, which are subroutine 
numbers indicating one of the 46 subroutines, or 0, 

d. The indicated subroutines are executed in the specified 
order. An entry of 0 terminates the list. 

For example, consider the instruction 00230220g, Based on the first 
six bits^ the OOg table is selected. Based on the next six bits, the 
23g entry is selected. This entry is: 



PRR 


2 


1 


0 



The opcode, ^PRR', is extracted. Subroutine 2 is executed. It 
extracts the last six bits, 20g, determines that this indicates 
'register A', and replaces the third character of the opcode by 'A', 
obtaining 'PRA', Then subroutine 1 is called, looking up the next- 
to-the-last 'six bits, Q2g, translating this to 'register J.', and obtain- 
ing the opcode 'PJA' (Positive of J to A), The various subroutines 
might also construct the operand field (PJA has no operands). This 

< 
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implementation is unusual, so siich complexity- may not be 
required. The method, however, should be implementable in an 
HOL, using an array of subroutines or a CASE statement to select 
the subroutine calls. With a simpler machine, thil5 sort of p'rjpcess- 
ing can be done nicely using a programmer-specified table to define r 
(or overlay, really) the instruction word. The table will have variant * 
record types, i.e., different definitions of the word, based on th^ 
various Instruction formats. The necessary fields can be accessed 
directly without explicit bit extraction. The DC 6024/4 machine, 
however-, might have too many instruction formats for this to be 
practical. 

Another area where bit manipulation is necessary is in some 
types of number conversions. These usually involve 4ogical or' 
and shift operations. "It is" possible to do this without shifts, ^ • 

technically. One UPT FQRTRAN program for formatting display 
screen images (Box 4 of diagram A35) does conver sion^using addition 
instead of logical or's, and multiplication , and division by powers, of . 
two instead of shifts. This, does not enhance readability , ^however , 
and could be very inefficient if the multiplications and-divisicJns do 
not compile as shifts. 

Bit accessing is occasionally used in 'coding tricks ^ to^ gain 
efficiency. For. example, in the 214A Visual System (diagram A335), 
the code used to implement the test . 

'*If cockpit = 2 or 3, return to caller" 

is: 

BITB #2,QCKPT 
' BEQ V$560A 
JMP: V$'560Z 

, A compiler could probably not be expected to generate such a test, even 
if it was- known that the range of QCKPT was 1-4. However, only 
two instructions are saved over a more explicit translation of the 
IF statement. 

5. 2. 5 Boolean Data Typ e 

Certain simulator areas involve large quantities of Boolean, 
or logical, data. This is particularly true in the Navigation and 
Communications area (diagram A332;- Much of the data correspond? 
to rdware- input and output values. Tn fact, the datapool allows 
specification of 10 different type^; of >^^oolean items; 

VB - logical bit 

DI - discrete digital input 

LO - discrete lamp driver level output 
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test bit 2 of cockpit, number 
if off, execute program 
otherwise, jump to last statement 



DO 


discrete logical level output 


WI 


- hardware bounded digital word input 


WL 


- hardware bounded lamp driver level word output 


WD 


- hardware 'lounded logic level word output 


PI 


- software bounded digital word input 


PL 


- software bounded lamp driver level word output 


PD 


- software bounded logic level word output 

I 



A major issue with Boolean data is the degree of packing used, 
with a tradeoff between space us^ed and speed of access. One objec- 
tion to FORTRAN expressed at Link was the necessity of allocating 
full words to logical values. The programs studied allocate logicals 
to bits, bytes, and words, depending on the type of efficiency required. 

The 214A Visual'System (diagram A335) uses many 
Booleans for flags and indicators. THese are all represented 
by bytes, the minimum addressable unit on the PDP-11. Two 
x^xceptions were noted where bit data was used for flags. In one 
distance, three bits in one byte were used as flags indicating that 
•,ne roll; pitch, and heading of the probe are in sync 'with the aircraft. 
There is no particular use made of the fact that the flags are stored 
this way - it is just done to save two bytes. Since the machine has 
bit set and test instructions, there is no additional cost in processing. 
In the other case, the four top bits of a word are set to indicate which 
of four cultural lighting boxes are to be turned on. The code which 
turns on the boxes is a loop which shifts this v.'ord left and tests if it 
becomes negative (sign bit set) to determine whether to turn on each 
box. An array of Booleans, which'could be accessed by the loop 
index already in use, would support this concept equally well. Pack- 
ing would be required if only one word was to be used. 

Many packed Booleans are also used. In the Hydraulic. Systems 
area (diagram A33133), for example, 14 flags dealing with landing gear 
and landing gear door positions are packed in a single word. Communi- 
cations Booleans are also often packed. These are hardware inputs, an 
the packing is- thaV^deterrfiined by the hardware. If the packing could be 
^^speeif led appropriately, organization of th: s data into tables would 
improve clarity. For example, consider the actual-input layout 
described in Figure 5-3. For logical purposes, this data should be 
treated as a table indexed by operator and cockpit (except NOIPTT 
and N02PTT, which coj-respond to operator only). This could 
be represented by a PL/I structure (see also Section 5. 3. 4) such as: 

DECLARE 1 NRADIO (1:2), indexed by operator 

2 NOPTT, operator push to talk 

2 NCKPT (1:4), indexed by cockpit 
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Figure 5-3. Communications Input Word Layout 



3 NOXV, VHF xmit selected 

3 NOOS, override selected 

3 NOIS, instructor selected 

3 NOUR, .UHF receive selected 

3 NOUX; UHF xmit selected 

The only problem with this is that there is no apparent way to describe 
how the bits are actually packed, (It is possible that the data could be 
repacked appropriately by the executive, or that the packing coming 
from the harflware could be altered.) The program currently must 
perform complex bit manipulation to access data in the order desired, 
anyway. For example, one sequence of code, with the objective of 
obtaining N014UX, N013UX, N012UX, NOllUX packed into the right- 
most four bits of a single word, proceeds aswfollows: 

a. load word 2 

b. mask to zero all bits except bit 14 (NOllUX) 

c. shift left 3 (into bit 17) 

d. save result 

e. load word 1 I 



f. rotate right 5 (to get the 5 bits into the |iigh-order 
bits) 

g. mask to zero all bits except the top 5 

h. add the word previously saved (bits 23, 21, 19, 17 
now contain desired values) 

clear the accumulator extension (extends on high- 
order end) 

j. do 4 times: 

il. shift left double 1 bit (sliift desired bit into 
extension) 

j2. shift left (single) 1 bit (drop unwanted bit) 

k. extension now contains desired result 

The amount of processing involved makes reformatting in the 
executive seem like a reasonable alternative. 
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Various documentation techniques are used to describe 
Boolean equations. Some programs use English; as in this example > 
from the 214A Visual System (diagram A335), determining if the 
aircraft is above the clouds: 

ABOVE CLOUDS IF • 
OFF MODEL AREA OR 
OUT OF TOLERANCE OR 
• LIGHTS NOT READY OR 

COMMANDED POSITION CHANGE TOO BIG OR 
PROBE NOT IN SYNC OR 

A/C ALT > CEIL + FIELD ALT + CLOUD THICKNESS 

Some use FORTRAN or pseudo - FORTRAN, as in this example from 
Flight Controls (diagram A331): v. 

FELTRD - TMPLOl .AND. .NOT. (UMLTRE. LT. UMLTCE) .OR. 
.NOT. FELTRD. AND. (FTRIME . LT. 25) . AND. 
UMLTRE .OR. UMLTCE. AND. (FELTRD . OR. 
TMPLOl .AND. .NOT. FELTRU) • 

J ^ 

A decision table representation (see Section 5.4.4.1 for examples)'' 
would be mpre readable but might require some simplific^t;ion by,.the 
programmer. A less unwieldy notation than that^of FORTRAN-^ouIcJ 
also be helpful. Use of longer and more descriptive names might \ 
also improve readability, though it would make the expression even ^ 
longer. 

Another documentation technique, from the Communications 
area (diagram A332, Box 1), using data from Figure 5-3, is: 



OIVXN = OIPTT • OllXV • Olios • OllIS 
= OIPTT 2 2 Z 

= OIPTT 3 3 3 

= OIPTT 4 4 4 

In this assignment, the cockpit number (1-4) is used to determine. which 
of the four lines applies. The implementation of this expression is 
interesting, and represents a degree of efficiency which might' be 
difficult to obtain in an HOL. For example. 



OVXN(l) = NOT (OPTT(l) AND OXV(l,CKPT) AND NOT 
OOS(l,CKPT) AND NOT OIS(l,CKPT)) 



would be a reasonable HOL expression of the equation using the data ■ 
structure described previously. (See Figure 5-3 for allocation of 
the bits; these are the same variables without the initial 'N's,) 

The actual implementation is: 

a. Set OIVXN = true. 

b. ^ Using a mask obtained from a table of four masks 

indexed by-cockpit number, mask input word 2 to 
clear all bits except OIPTT, OlnXV, OlnOS, and 
OlnlS- (n is the cockpit number) 

c. Compare result to another value, also obSfined from a 
— table of four indexed by cockpit, which has bits set in 

thepiPTT and OlnXV positions only, 

d. If equal, set OIVXN = false. 

This sequence takes advantage of the fact that only one possible set of 
values. 



OIPTT, OlnXV, OlnOS, OlnlS 

will result in a value of false for the equation. It uses only seven 
machine instructions. However, a programmer who has done the 
necessary analysis to discover that this is possible could instead 
write: 

OVXN(l) = (NOW2I(l) AND MASK(CKPT)) NE MVAL(CKPT) 

masking and comparing to the desired masked value. Unfortunately, 
the intent of the operation is no longer clear. 

Another example (from the same program) of efficiency 
gained by explicit knowledge of the Boolean packing is the implementa 

tion of the three successive equations: 

■^-^ ^ 

N01SPR= .NOT. (NOSPON .AND. NSPROl .AND. .NOT. 
NOIPTT .AND. .NO"^ N02PTT) 
' NO'ZSPR = .NOT.; (NOSPON .AND. NEPROZ .AND. . "OT. 

NOlP^T .AND. .NOT. N02PTT) •■ ■ 

NMONSR = '. NOT. (NOSPON . AND. .NOT. NSPROl .AND. 

.NOT. NSPR02 .AND. .NOT. NOIPTT .AND. 
. NOT. NOIPTT) 



The variables that the equations have in common, NOSPON, NOIPTT, 
and N02PTT are tested first. If NOSPON is false or NOIPTT or 
N02PTT are true, all three expressions are true. To obtain the 
same degr^ of efficiency, an HOL implementation would probably 
have to make this test explicitly, e.g., 

IF NOIPTT OR N02PTT OR NOT NOSPON THEN 
BEGIN 
NOISPR =1; 
N02SPR =1; 
NMONSR =1; 



/ 



END 

ELSE 

B EGIN 

NOISPR = NOT NSPROl; 
N02SPR = NOT NSPR02; 

NMONSR = NOT (NOT NSPR^l AND NOT NSPR02); 
END • 

The IF~THEN-ELSE expression of the problem seems more under- 
standable as weir as more efficient. That, and the fact that it. is 
actually implemented this way, indicate that the equations were / 
probably derived this way and then converted to the '^single assign- 
ment statement for each variable" form for documertation purposes. 
Therefore, it doesn't seem tha'. expressing the equation in the more 
efficient form in an HOL. would be a problem for the programmers. 

5. 2. 6 Character String Data Type 

Character processing is not significantly used in the main 
aircraft modelling portion of the simulator (i. e. , that processing 
illustrated by diagram A33). However, it is required for display 
I/O in the Training or Instru,ctor area (see diagram A35), for 
numerous offline support programs (which create data files used 
during simulation) and for debugging support (e. g. , Math Model 
Test, Box 2 of diagram A2). 

5. 2. 6.^1 Offline Character Processing Requirements * 

The offline^V^^ograms process card image input and some 
produce printed output. Programs which create offline data files 
include : 

radio station file creation (Box 4 of diagram A332). 
malfunction compiler (Box 3 of diagram A35) 
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initial condition file creation (Box 2 of diagram A35) 

screen image file creation (Box 4 of diagram A35) 

map plate compiler (Box 5 of diagram A35) 

tactics scenario file creation (diagram A334) 

radar emitter data file creation (Box 3 of diagram A334) 

These offline programs have the text processing requirements 
characteristic of compilers. Operations such as the PL/ 1 INDEX 
and SUBSTR functiohs seem desirable . However, nouses of varying 
length character strings wer^ noticed. 

As an example of text processing requirements, the radio 
station file creation program fBox 4/of diagram A35) requires interpre- 
tation of input commands, testing of indi-vidual characters in strings, 
and insertion of individual characters into strings'. This processing 
•is implemented in FORTRAN using, octal equivalents of the characters. 
Direot language support of character handling would result in much 
more readable code. 

i - 

In the I/O performed by the offline prograrhs, conversions 
between numeric forms and ASCII character strings are required.^ 
Some of these conversions could perhaps be supported by the I/O 
features of an HOL, partictilarly in output conversions. Input con- 
versions are more difficult. To process a statement like 

INPT var, value r 

from the Math Model Test program (Box 2 of diagram A2), the variable 
would-have to be read and looked up in the datapool. Then the value 
would have to be read based on the variable type. (The input format 
might also have to be more fixed. ) In an HOL, this could probably 
best be done by simply reading the card as a character string and 
then invoking an explicit conversion of the appropriate substring. 
• (Another problem witli trying to rea:U or write with the various for- 
mats is that fixed point formats involve scaling information as 
well as type. ) 

5. 2. 6. 2 Display Character Prociessing 

Display character data is constructed and output by the 
Instructor System programs (diagram A35). Typically a different 
' character set than that of the CPU will be used by the display. In any 
•case, some of the display characters will be display commands or 
orders, and these would not be representable, as characters of the 
computer. An HOL should provide some means of defining bytes ^ 
representing .these chai;acters by specifying the bit equivalent and 
then using the ae-^PT character manipulation expressions. 

/ 
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Display I/O ordinarily involves a block transfer, i. e. , a 
movement of blocks of characters by a hardware operation to the 
display memory. The display memory may have a different word 
length than the CPU. In the UPT system, which uses an Aydin 
display, for example, the Aydin memory has l6-bit' words, while 
the computer has ^4-bit words. On input from the Aydin, each ' 
l6-bit word is stored right- justified in a 24-bit word. On output, 
however, the l6-bit words are packed into the 24-bit words as 
follows: 



0 
1 



1 

AYDIN 0 


[ 

AYDIN 1 (MSH) 


AYDIN 1 (LSH) 


AYDIN Z • 


AYDIN 3 


AYDIN 4 (MSH) 


AYDIN 4 (LSH) 


AYDIN 5 


V . ^ 



24-bit words 



Construction of Aydin data involves conversion from the Harrils ASCII 
code to the display code, as well as insertion of l6-bit display 
commands. Packing of the Aydin words into Harris words also 
requires some bit handling, i.e., shift and logical ^or^ Some 
programs .v^nstruct the entire Aydin image with l6 bits /word and 
then ca'ii a routine to pack it. Interpreting Aydin input as character 
strings rec^aires extracting the rightmost 2 bytes of each word and 
packing th( til into a string. 

5.2.7 Poin ter Data Type 

In the programs studied, which are primarily in assembly 
lcing\v-ige, uses of address data must be examined to determine possible 
r-Bquiremept? for pointers in an HOL. Most address data is 
srmply use^ point to a table element, and thus it corresponds to 
array or >ie indices (or subscripts) in an HOL. Some addresses 
are u . . subroutine parameters to indicate the address of an input 
tablCc ' In an HOL this could be accomplished through call -by- 
reference parameters rather than with explicit use of addresses. 
Some useK of addresses for list processing functions correspond 
more logically to HOL pointers. Another use, which is not precisely 
a use of pointers, is the accessing of a memory location given its^ 
address, . 



5. 2. ?• 1 List Processing Pointer Usage 



The UPT monitor (box 1 of diagram A3) uses queues in which 
the elements are linked by pointers. TJiere are two types of queues 
us^d: I/O request queues and an error request queue. The error 
request queue is circular, while the I/O queues are FIFO queues, 
Botli queue types are constructed by request handling routines. These 
routifie^ receive an input parameter that is the address of (pointer to) 
a parameter table for the request. They then insert this table into the 
appropriate chain, (Figure 5-4 ilPustrates an I/O request parameter 
table, ) Queue elements are removed (unlinked) aft^r being proces.sed 
by the appropriate request handler. Note that the I/O request chain 
uses variant record types; the i-ecord type is determined by the'T-YPE 
field in word 0, (see Section 5. 3, 4 for a discussion of tables andV 
records, ) * ^ 

. ' '! 

In the tactics area (diagram A334) pointers are used to chain 
display data. Also, data is sorted by sorting a list of pointers to the 
data rather than sorting the actual data, \ 

5, 2, 7, 2 Accessing Memory by Address 

The accessing (either reading'or setting) of a memory location 
given its ^ddress is one function required in the testing areas, i.e. , 
Math Model Test (Box 2 of diagram A2) and Remote Decimal Readout 
(Box 3 of diagram A2), and in the programs associated with the instruc- 
tor display/setting of datapool values (Box-4 of diagram A35), For 
example, the Remote Decimal Readout program provides access to core 
locations based on octal address. Similar^/, the Math Model Test pro- 
gram provicjes a symbolic debugging capability, i.e. , setting of data- 
pool variables or printout of their values. 

In a system written using an HOL, some such debugging 
system would still be useful. It might be availSible as a general tool 
provided with the HOL, i.e. , a general-purpose symbolic debugger . 
based on the global data base facility, or it might be implemented 
by the. user. In either case, it should be possible to program the 
debugger in the HOL. Implementation of a debugger requires the 
same use of addresses as required by the display programs. 
Specifically, a symbolic datapool' name specified by the programmer 
is looked up in the datapool and its address is obtained. The address 
must then be used to access the value of the symbt)l in order to 
display or alter it. 

This function is probably, not required in general-purpose HOLs, 
and it can lead to security problems. However, it is required in 
order to implement these simulator support programs. Sorn^ HOLs 
support it, but not very directly. For e^tample, a PL/I pointer 
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CPU 



TYPE 
E 

CHAIN 

BUFFER 

ADDRESS 

WORD/BYTE 
COUNT 



m REQUESTING CPU (1,2,3) 
- PRIORITY IX) • H 

HI - 1 (RESERVED FOR DEHO/RECORD/REPLAY) 

• TRANSFER TYPE (INCLUDES DEVICE CODE) 
° ERROR FLAG 

• POINTER TO K^XT PARM ^ 



ALL 



VTSC 



€rr. 
Oxsc 



l.olc f.eld,F.-(led in fcy i/o re^u«f handler 



- MEMORY ADDRESS OF BUFFER TO/FROM WHICH DATA WILL BE 
TRANSFERRED 

- MAXIMUM NUMBER OF WORDS/BYTXS TO TRANSFER 
AYDIN ONLY 



DATA FIELD 



ADDRESS OR REGISTER ASSOCIATED WITH TYPE FOR AYDIN 
COMMAND 



v;ORD OFFSET 



SUBFILE f 
AFN 



DISC ONLY 

OFFSET INTO FILE (MUST BE SECTOR BOUNDARY FOR WRITES.) 
OFFSETS INTO SUBFILES ARE NOT ALLOWED. 
NUMBER OF SUBFILE TO READ FROM INDEXED FILE. 
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BUFFER 
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^MAXIMUM NUMBER OF WORDS TO TRANSFER ON THE EXTENDED 
. INDL\ED READ 



Figure 5-4. I/O Parameter List Structure 
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variable could be overlaid with an integer containing the correct 
address. Alternatively, in PL/I and in some JOVIAL imprementa- 
tions, an array cokld be overlaid to location zero, and accessed 
using the address as a subscript. Neither of these methods is 
particularly desirable, however. Some means of providing symbolic 
debugging, etc. (perhaps using another technique) should be available 
in a simulation HOL. 

5.2.8 Label Data Type 

In the simulators studied, only one instance was observed 
which might best be implemented with a label data type, specifically 
with an array of labels, though other alternatives are possible. This 
is task dispatching using the foreground task table (diagram A312), 
which would most likely not use the same table representation in an 
HOL. The current task table entries are of the form: 



0 


program ID 




used in reporting errors 


1 


cockpit/frame mask 




—described in Section 3, 1 


2 


start address 




— address to which to 








transfer control 


3 


worst case time 




■^longest time used by this 








Droeram-tested and 



updated if necessary 
after each execution of 
the program 

In an HOL implementation, program start addresses stored in a 
table would not be convenient for executing the programs in sequence. 
On the other hand, a sequence of calls cam^ot be used because of all 
the checking that must be repeated, e.g.: ^^ 

IF PROGRAMl IN THIS COCKPIT AND FRAME THEN 
N BEGIN 

CALL PROGPAMl 

IF PROGRAMl_TIME >PROGRAMl_WORST»CASE- 
TIME THEN PROGRAMl_WORST_CASE_ 
TIME = PROGRAM 1_TIME 

END 

IF PROGRAM2. . . 



etc . 



Another example is the "conversion control list, " a list of 
values to, be converted to Aydin form in the Instructor System (Box 4 
of diagram A35). Included in the table is a word specifying the 
number of entries. This word is actually used '-^y the conversion 
subroutine to determine table size. An HOL implementation could 
use this same approach; in .which length is actually included in the 
table and explicitly extracted by the routine using it. Alternatively, 
it could provide varying length tables', which might be implemented 
the same way, but invisibly to the user. 

5 . 3. 4 1 . 4 Variant Record Types 

One. possible use of variant record types was discussed in 
Section 5.2.4, in connection with 'the Math Model Test trace formatting 
(Box 2 of diagram A2). Other ifses occur in the files containing sur- 
face radio station data (Box 4 of diagram A332) and radar emitter data 
(Box 1 of diagram 'A334). These files contain different record types 
for each radio type or emitter type. 

5.3.4.1.5 Non-Distinct Component Names 

There are many instances in the programs studied where 
several tables have the same organization and kinds of components. 
Some con;*enient notation for this would be useful, e.g. , from the 
214A visual system visibility effects program (Box 4 of diagram - 
A3354):' 

TABLE UICDATA 7; "old instructor inputs" 
BEGIN 



ITEM CCLG 
ITEM CCTH 
ITEM CDDN 
ITEM CMIN _ 
ITEM CRND 
ITEM CSTG 
ITEM CVIS _ 
END 



"cloud ceiling" 

"cloud thickness" 

"day /dusk/night indicator" 

"minimum lighting" 

."random lighting" 

"stagefield lighting" 

"visibility" 



TABLE VICDATA LIKE UICDATA; "new instructor inputs ' 

Of course, some means of distinguishing between components of the tw 
tables is then required. There are instances where one such table is 
assigned to a co rre sponding. one . A convenient notation for this, e. g. , 

ENTRY(UICDATA, 0) = ENTRY( VICDATA, 0) 
or simply 

UICDATA = \n:CDATA 
would be useful. r; > 



word 0 

word 1 
word 2 
word 3 



data ready bits 



logical complement of 
15 rnsb of x feedback 



same for y feedback 



same for z feedback 



V 



note: signals are 
inverted 




Ir— logical complement of z Isb 
I — same for y 
same for x 



It would be difficult for a high-level language to support direct 
extraction of the l6-bit feedback values, (However, perhaps the data 
organizaLion could be changed as discussed in. Section 5. 2. 5. ) 

Another use of programmer - specified tables is described in 
connection with the Math Model Test (Box 2 of diagram A2) trace 
feature (Section 5.2,4), 



5, 3,4. 1.2 Serial vs. Parallel Organization 

In tables constructed to match hardware inputs or outputs, as 
discussed above, the choice of serial or parallel organization should 
probably be left to the progr.ammer. For example, the UPT system's 
AST Linkage requires parallel organization. Most tables which would 
be constructed from what are currently separate data items could 
equally well be represented logically by either organization and both 
are used in current implementations. The major reason to select one 
method over the other is to facilitate data accessing as it is done in the 
particular table. Since simulators have significant efficiency 
requirements , this option should probably be made available to 
prog rammers . 

5.3.4.1.3 Variable Length Table s 

Little use of tables with dynamically varying length was 
observed in the programs studied. An example of such tables, however, 
occurs with the foreground task table (Box 3 of diagram. A3 1 2) 
illustrated in Section 5. 2. 8. This table is preceded in core by its • 
number of entries. This raimber is reset to zero if the operator, at 
initialization, specified a "maintenance and test" load (Box 1 of diagram 
A2). ^It could potentially be changed dynamically to any value and 
then be used by the foreground dispatcher. However, it should not 
be because the task table is preset and not changed during execution. 
There is no reason this special case couldn't simply be implemented 
with a flag indicating "maintenance and test. " 
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Figure 5-7. Master Disk Directory Entry 
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If desii-ed, an enumeration type describing the conditionb 
represented by the flags (GPUPRP, GPUBST, etc.) 
could be used to index the arrays. A table could be 
used to combine the. two arrays, e. g. , 



TABLE DCLOAD(l:N) 
BEGIN 

ITEM FLAG Boolean 
ITEM LOAD Integer . 
END 

The second method would probably result in more efficient generated 
code, and its intent is clearer. 

5 .3.4 Structure Data Type 

As mentioned previously, much simulator data could logically 
be organized into structures (or tables) which group related items 
together. Several examples have a,lready been given, for example 
in Sections 2. 3.2 and 2.5. Most structures would replace many 
data items >vhi(ch now all have individual names, with indexable 
structures'"^ thus using fewer names. The following sections discuss 
structure organizations used, structure operations required, and 
examples of major simulator structures. 

5.3.4.1 Structure Or^ganization 

5.3.4.1.1 Prog rammer- Specified Allocation^ 

Allocation of components within a structure may be 
accomplished automatically by a compiier or may be specified 
explicitly by the prcgrammer. Programmer specified packing seems 
necessary in cases where tbr table describes data for an I/O interface 
Examples of this are the master disk directory, illustrated in Figure 
5-7; the construction of I/O command words by the I/O routines, and 
the interpretation of device status words. (Perhaps a status word 
could be represerted as a set (see Section 5. 3. 1) rather than as a 
programmer- specified table, since in general each bit represents a 
discrete condition- ) One example of I/O -'ata which might be 
difficult to handle in this way, however, occurs in the 214A visual 
system gantry feedback processing (Box 1 diagram A3352), wliich 
has as an input the table: 
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30$: MOV VXPFB1(R4) VXPFBT(R5) ''move' 
ADD #2,R5 "update indices" 

ADD #4,R4 

SOB R3, 30$ "subtract one and branch" 

A better implementation is simply: 

MOV \rKPFBl, VXPFBT 
MOV VYPFBl, VYPFBT 
MOV VZPFBl , VZPFBT 

An HOL implementation of operations on vectors shoul'''' be sophisticated 
enough to use loops when more efficient, ao in the first example, and 
repeated code when this is preferable, as in the second. 

Another possibility of, matrix or array use occurs in the 
computation of DC bus load in the Electrical- System (Box 2 of 
diagram A33132). Here the bus load is initialized to 15 and then 
various device flags are tested; appropriate values are added to the 
bus load for each device which is on, i, e, 

LLDBUS =15 

IF (GPUPRP) LLDBUS = LLDBUS + 3 
IF (GPUBST) LLDBUS = LLDBUS + 17 



There are quite a number of tests, leading one,^to look for a simpler 
representation. Possibilities are: 

a. The flags could be considered a 1 x n matrix of I's 
and O's, and the loads an n x 1 matrix of values. 
Matrix multiplication will then^^^^ the sum of 
selected loads , e.g., 

• LLDBUS = 15 + [FLAGS] [LOADS] 

b. If the flags are an array of n Booleans, and the loads 
an array of n values, aloop'canbeused, e.g., 

LLDBUS = 13; 
FOR I = 1 TO N; 
BEGIN 

IF FLAG(I) THEN LLDBUS = LLDBUS + LOAD(I); 
END 

56. 



A simulation HOL should provide some support for vector 
aiid matrix operations. One program, the 214A Visual Position 
and Velocity program (Box 2 diagram A335 1), performs matrix 
and vector operations almost tixclusively. It could be rewritten in 
about 20 lines in a language supporting these operations (instead of ■ 
its currenw 409 lines of assembly language). Such operations would 
ha^'e to alhnv different scalings of the operands as well as operations 
in which ont- operand i s 'single -word and the other is double-word 
(oper< .ids are of different precisions). Operations used are: 

adiition and subtraction of vectors 
multiplication of a vector by a scalar 
multiplication of a vector by a matrix 
cross product of vectors 
dot product of vectors 

In one example from the visual programs, a vector is 
multiplied by a rotation matrix of the form.: 

COS xl -SJN \P 

-SIX -COS C 

U 0 

The code used cakes advantage of the O's and-1 in the matrix and does 
not perform the full multiplication. In a high level language, the 
programmer could obtain this result by writing the multiplication 
out explicitly on an e 1 e ment - by - el em^e nt basis. Possibly, though, 
the multiplication pro\'idcd might include checks for zero elements. 

Efficient compilation of matrix operations is important. Some 
possible difficulties which might be encountered were observed in the 
way the 214A visual programs are currently implemented. For 
example, the programs frequently fail to use loops when performing 
the same operation ( n the three elements of a vi'ctor. This can result 
in a considerable iticrease in program size with little saving in speed. 
In one instance, a 21 -word operation is repeated three tinies , . ratlier 
than using a loop. Tf a loop setup requires' 5 words, a loop iniple- 
mentation would require 2(') words rather than the i~^3 used by tlie actual 
implementation. On the other hand, there is one instance -vliere a loop 
is used to accomplish the equivalent of three MOV instructions. The 
code used ii. : 

MOV f^3,R3 "counter" 

CLR R4 "two different offsets required" 

CLR R5 



0 

-1 



Files created offline and used online during simulation 

.include: 



radio station file (Box 4 of diagram A332) 
initial condition file (Box 2 of diagram A35) 
malfunction file (Box 3 of diagram A35) 
CRT screen image file (Box 4 of diagram A35) 
map plate file (Box 5 of diagram A35) 

Files created offline and used online during simulator 
testing only include: 

datapool, or symbol dictionary: used during Math Model 
Test (Box 2 of diagram A2) in support of symbolic debugging; 

maintenance and test input file: used in executive I/O test 
(Box 1 of diagram A2); this file contains names and 
displacements w,ithin blocks for the maintenance ^nd test 
load analog and digital input variables; 

hardware cross-reference file: lists' the names of the 
symbols which are input and/or o^itput variables used by 
AST Master Controller to communicate with simulator - 
hardware (see Box 4 of diagram A3); this file is used for 
error diagnostic printout during AST test runs; 

Files created offline and used offline include: 

datapool: used offline to obtain symbol definitions daring 
compilation/assembly (Boxes 1, 3 of diagram Al) 

. system cross-reference file: maintained throughout system 
development (diagram Al) 

/ 

various data files (airfield data, etc.) use d by -ihe map 
plate compiler (Box 5 of diagram A35) 

i 

5. 3. 3 Array Data Type 

Throughout the simulators studied, readability could be 
much enhanced by grouping various related items into data aggregates. 
In general, most of these groupings- would correspond to tables or 
structures, as described in Section 5. 3. 4. One exception i.s the vector 
and matrix data which is heavily used in the -Aerodynamics (diagram 
A3312), Tactics (diagram A334), and Visual (diagram A335) areas. 
These vectors represent flight data (e. g. , the accelerations and. 
velocities computed in the equations of motion program -- Box" 5 
of diagram A3312), and contain three elements corresponding to X, 
Y, and Z coordinatiss. 
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^ 



1 



^JXrces 
DATA 



HEADER: Ist WD ALWAYS ^ 

2nd WD M^xlimnn iire of allowable iub-file entries 

3rd WD Location of fir»t available data spare 

4th WD Latest date of file revision 



INDEX: 



Sub-File Indiciffs are order dependent (i.e., 1st Index • 

Sub-File #1, 2nd Index - Sub-File »2, •tc.) 

1st WD Start location of tub-file data (0 • NO ENTRY) 

'2r.j WD Sub-file size 

3rd wn Sub-file checksum 

4th WD Latest date of sub-file revision 



DATA: Sub-file Data areas are non-order dependent thus allowing 

sub-file additions in any order without having to restructure 
file. 



Figure 5-6. Indexed File Structure 
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Figure 5-5. Intercomputer Communications Parameter Word 



In the UPT training system, a demo; request mask is' used 
in conjunction with the frame masks. (See demo/ record/playback, 
Box 1 of diagram A35. ) The demo request mask contains 15 bits, 
one of which is set to indicate the demo requested by. the instructor. 
A corresponding 15-bit value indicates which of the demes are 
available in the file. A set data type could also be used for this. 

Bit strings are also used as parameters to the background 
dispatcher and to the intercomputer communicaiions routine. The 
parameter to each routine is a string of bits in which each bit position 
represents one of the functions requested. -The bit is set to 1 for each 
requested function. The sign bit is always 0, and the bits immediately 
to its left represent the functions in order/ of decreasing priority (see 
Figure 5-5). The routine must determine the leftmost 1 bit which is 
set. This is implemented by a floating point normalize instruction, 
which shifts the rightmost 23 bits left until bit positions 0 and 1 differ 
(i.e., bit 22 = 1 ) and returns the shift count. The parameter word 
could certainly be implemented as a set in an HOL, and priority of 
functions could be represented if this set is a power set of an ordered 
enumeration type. It isn't clear, though, how the operation "find ^ 
the highest element" could be represented so that it could be expected 
to compile to a floating point normalize, or even a "find the leftmost 
1 bit" instruction. 

Another uac- cf bit string data occurs in malfunction simulation 
(Box. 3 of diagram A35). Expressions from the malfunction dXta set 
are evaluated, and when one isifound to be true, the indicated mal- 
function is turned on by s'etting one of 96 bits in a packed 4-word 
array of bits. These bits might be specified as a set data type. 

5. 3. 2 File Data Type 

This section describes the disk files used in the simulators 
studied. Other I/O issues, as well as the actual disk I /O ^pr oce s sing , 
are discussed in Section 5.6. 

The simulator monitor provides disk I/O capability, supporting 
both direct and indexed files. Figure 5-6 illustrates the indexed file 
structure. The functions provided are direct read and write, indexed 
read (writes must be made by trbating the file as a direct access file), 
and extended index read (in which two contiguous subfiles of an 
indexed file may be read into different parts of memory in one 
request)* 

Disk files created and used during simulation include: 

demo recording file (Box 1 of diagram A35) 
track history file (Box 6 of diagram A35) 



The cockpit mask includes a 1 bit for each cockpit to which the task 
applies. Some programs must be called for each cockpit, while 
others are non-cockpit dependent and need be called only once per 
frame. The visual progragns are called for only two of the cockpits. 
The frame mask here indicates during which frames the task is to be 
executed. The simulation prograras will execute at 20, 10, 5, 2, or 
1 frame/cycle. Some training programs do not require equal spacing 
.and use rates other than these. The sequencing through the fore- 
ground task table for a given frame is essentially: 

FOR COCKPIT = l<TO 4 "SEQUENCE THROUGH COCKPITS" 
BEGIN 

IF COCKPIT ENABLED 
. BEGIN 

FOR TASK r: 1 TO N "SEQUENCE THROUGH TASKS" 
BEGIN 

IF TASK THIS COCKPIT AND FRAME "MASK" 
CALL TASK 

END 

END 
END 

This is actually somewhat mort- complicated, because cockpits 3 and 
4 are 1/2 cycle out of phase with cockpits 1 and 2, so that their frame 
10 is at the same time az-s cockpits 1 and 2 frame 0. This is required 
to prevent buffer use conf'^cts during record/playback (Box 1 of 
diagram A35). Thus, in , above loop, the frame mask (the one 
indicating which frame is currently active) is shifted 10 bit positions 
after cockpit 2 processing. 

' With all this shifting goii^g on and the need to check for a shift 
out of bit 19 each time, this code doesn't seem so efficient that an HOL 
need replicate it. Besides, it is dependent on the fact that 

word size^# of cockpits -f // of frames /cycle 

An HOL implementation could use a set data b/pe to represent the cock- 
pit and frame indicators in each task table entry and to represent the 
set of enabled cockpits. The active cockpit and frame woiild be loop 
indices, which would be tested for inclusion in the seti; of cockpit and 
frame indiccttors for each task. 
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The first and third cases here could certainly be handled other ways, 
either using fljags or a different grouping of functions. The second 
case is a little more complicated because a subroutine is used. (Actually 
an interrupt handler is used, but interrupts here cause execution of 
one of a table of subroutine calls. ) The subroutine must be able to 
return either to the routine which invoked it or to the routine which 
invoked that routine (the dispatcher). Other inte rrupt. handle rs do not 
return at all to the routine which was interrupted (e. g. , for an 
interrupt caused by the key used to stop TTY output). This is related 
to the problem of describing interrupt handling in an KOL (see 
Section 5.7). 

5. 3 Aggregate Data Types 

5. 3. 1 S et Data Type 

As mentioned in Section 5. 2. 4, some uses of bit string data 
in the simulators studied correspond more lojgically to an HOL set 
type. An example is the use of bit strings in the monitor for frame 
-and cockpit mask? (see diagram A312). The frame mask is a string 
of 20 bits, one of which is on to indicate which of the 20 frames is 
active. The cockpit mask is a string of four bits, one representing 
each cockpit. A bit in the cockpit mask is on if the cockpit is in use 
during the particular simulation run. The cockpit mask is constructed 
at ir\.itialization time, .based on operator input in response to the 
question 'COCKPIT ENABLES? and remains constant throughout the 
run. The frame mask is updated each frame by shifting. When the 
1 bit is shifted out of bit 19, it is put in bit 0. These masks are used 
in determining when to execute a task from the foreground task table. 
Each task entry Includes a 24-bit (1-word) cockpit/frame mask of 
the form: 



2322 21 20 19 


4 


3 


2 


1 


19 


18 







cockpit 



frame 
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^5... 2. 9. 3. 3 Internal Subroutine Calling 

There is cons idertible variation in the methods used to invoke 
internal subroutines. Techniques appear to be selected based on 
individual programmer preference. Most such routines are called 
directly. Various parameter passing methods are used. Sometimes 
parameters are passed in registers and "sometimes in local storage. 
Sometimes the -value is passed and sometimes its address (even in 
cases when it is not a table or array). Occasionally the address 
where the output is to be stored is passed to the routine, while in 
other cases the routine returns the output in a register. 

Most internal subroutines do not save and restore registers. 
A few of the subroutines within the monitor (background dispatcher, 
I/O request handler) must be reentrant and these do save and restore 
registers, using a local stack. 

Some internal routines have multiple entry points. For exampl 
a display program (Box 4 of A35) has two entry points (indicating 
start/stop refresh). This could be implemented differently, e.g., 
with a flag as a parameter. An HOL multiple entry point capability 
seems unnecessary and undesirable. 

The flow of control between monitor routines is handled in 
a variety of svays, Som.e routines have multiple entry points while 
others use instruction modification to alter control flow. For example 
from the UPT monitor; 

« One group of initialization routines (Box 1 of diagram 

A31)rare to be called only on the initial start and not 
on restarts, when other initialization is repeated. The 
calling instructions are changed to no-ops after the 
routines compl^te^ 

• A few interinipt handlers must (conditionally, not 
alv/ays) return to. the foreground dispatcher rather 
than to the application, prog ram which was interrupted. 
They do this by replacing the return address, saved 
in the first location of the interrupt handler at the 
call, by the desired return address Ln the dispatcher. 

« The Aydin "interrupt handler (as one example) is entered 
at the top as a result of an interrupt and at an internal 
entry point for the first Aydin request. When this 
internal entry point is used, the calling routine inserts 
the desired return address in the first location of the 
interrupt handler, and then makes a direct transfer to 
the entry point. 
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5.2.9.3.2 System Subroutine Calling 

In the UPT system, a single convention is used for all system 
subroutine^calls , a illust rated in the example in the previous section. 
Subroutines are called indirectly through pointers, perhaps to facilitate 
relocation. (This is not true in the 214A simulator. ) 

Almos,t all parameter passing is in registers. In cases where 
a parameter is an array or table (e. g. , LFI routines, I/O request 
handler) the parameter address is passed (call -by - refe rence in an 
HOD. In the LFI routines, there is a need for array parameters of 
varying sizes. In this implementation, the length is in a word preced- 
ing the array. A table parameter of varying length is also used by 
the display conversion ro.utine (Box 4 of diagram A35). This table 
is a Tonversion Control List - a list of values to be converted to 
Ay din form. 

None of the UPT system subroutines save and restore 
registers. The UPT machine does not have many registers and most 
are taken up v/ith parameters. The routines do leave the dedicated 
cockpit index registers (see Section 5. 1. 1) intact. 

In the 2"i4A system, calling of system subroutines is less 
consistent. The stack convention of the PDPll is rarely used. 
Generally, input parameters and returned values are passed in, 
registers, e. g. , from the 2 1 4A Visual System (diagram A335): 



MOV TEMP- 2, RO 

MOV VNRPTC, Rl 

MOV VNRALT, R2 

JSR PC, Z$LFI2 

MOV R2, VBDELN 



input s 

call (,note call is direct, unlike UPT) 
ou t pu t 



One executive subroutine is called with parameters passed in the 
temporary storage area (described in Section 5. 1.2) and with one 
parameter a global variable. For example^ also from the 214A 
Visual System: 



MOV 


ji 1 , VALTTB 


set datapool item to table •'• 


MO V 


«VFC1T, TEMP 


value table pointer (focusi 


MOV 


i-'VTLlT, TEMP^Z 


other value table pointer (tilt) 


MOV 


F VNRMPl , R3 


breakpoint table pointer (in register) 


JSR 


Z$VNOR 


normalize for LFI 


MOV 


RO, VNRPTC 


store result 



Apparently the routine Z$VNOR looks for parameters in the appropriate 
temporary and datapool locations. - 4 
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The use of inline functions inr^icates a choice of speed over 
space efficiency. Some fairly large subroutines are expanded a 
nurnber of times. For example, in the UPT aerodynamics system 
(dia^^am A3312): 



LIMFL - floating point limit 8 instructions - expanded 

24 times 

LIMlI - limit to 4^1.0 - 9 v" i tructions - expanded 

9 times 

LIMZN - limit to j^Z.O - 11 instructions - expanded 

8 times 

LFIL - LFI linear search - 17 instructions - expanded 

8 times 



An HOL should allow the programmer a similar control over time- 
space tradeoffs. Ideally, the specification of in}:ne expansion 
should be part of the subroutine definition; callt* for both types should 
be written in t'ne same way. This facilitates changing the method 
used (i.e. , only one definition, not numerous calls, must be 
changed) when tuning for the best time-space balance. 

In some cases within individual simulation programs studied, 
internal subroutines are used for operations which could be done 
much more efficiently inline, or with macros. Perhaps this reflects 
a desire to save space, but in at least one example, from the 214A 
Visual System (diagram A335), the extra code required to set up 
the subroutine call is such that this does not happen either. The 
use of the subroutine saves only one word of storage, and 34 more 
words are. executed than would be required in an inline implementation 

5.2.9.3 Subroutine Calling Conventions 

5.2.9.3.1 Main Simulation Program Calling 

As discussed in Section 5. 2. 8, these programs are called 
from the foreground dispatcher (diagram A312) with an indirect 
transfer to the task table address. No parameters ar.e passed; 
communication is through the datapool. 
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In addition to these routines, which are regarded as part of the 
monitor, the UPT system employs t^^/o general routines which access 
the surface radio facility data files (see Box 4 of diagram A332). 
These area: 



DDP 



RECEIVER 



(Digital Data Preselect) These subroutines are 
given a radio type and frequency from the air- 
craft dial. They search the preselect file to 
determine whether a station has been tuned. If 
one has, the ><Jata for. the. station is. read into 
core from the real time radio data file. There 
are 4 DDF^ subroutines , which correspond to 
TACAN, VOR,-DME, and ILS radio types. 

This subroutine uses the data that has been 
read into core and the aircraft data to compute 
ranges and bearings from the aircraft to the 
radio facility. 

Various system macros are also provided (see Section 5. 2. 9- 2). 
Functions provided by these include an LFI linear argument search, 
absolute value, and various limit functions (see Section 5. 2. 2. 2. 3). 

5.2.9.2 Inline Subroutines 

Both general purpose functions and functions specific to the 
various simulation programs are frequently implemented by macros, 
i.:e. , inline subroutines, rather than by actual subroutines. Some 
conditional assembly is employed'in the macros. For example, in 
one macro, omiission of the first parameter indicates that tlie 
parameter is already in the correct accumulator and need not be 
loaded. 

Actually, all UPT system subroutines are accessed through" 
macros* Tn the case of thes^ subroutines, the macros set up the 
parameters, call the executive routine, and store results. For 
example, the routine LFI2 (double variable LFI) is called by a macro 
of the form: 

LFI2 F200T, F200F,'R. FMAOII, R,FCL01I, R 



which expands to: 



TME 
TMA 
TOJ 
BSL- 



FCLOII, R 
FMAOII, R 
F200T 
ZLFI2 



TXM " F200F, R 



input parameters 
call 

store result 
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5. 2. 9 Procedure Data Type 



There are three main classes of procedures in the simulators 
studied. These are: 

a. The main simulation programs invoked through the 
foreground task table (as illustrated in diagram 
A31Z). 'These programs do not call one anotljer; each 
returns to the foreground dispatcher on compli^tion. 

b. System subroutines, which are invoked by the various 
simulation programs to perform general-purpose 
service functions. 

c. Subroutines internal to the main simulator programs. 

Various subroutine calling and parameter passing techniques are 
used, as discussed in Section 5.2.9.3. Pa rticularly in the subroutines 
internal to the main programs, there is a lack of consistency in; 
methods used. 

5. 2. 9. 1 System Subroutines 

The system subroutines provided in the UPT system are 
characteristic of those used in all simulators studied. These are: 

LFI argument search 
single variable LFI 
two variable LFI 
three variable LFI 
sine function 

cosine function (calls sine routine) 
arctangent function 
random number generator 
I/O request handler 

The F-14A and 214A simulrtors, unlike the UPT, include a single routine 
which computes both sine and cosine, as discussed in Section 5. 2. 2. 2. 1. 
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Alternatives would be an array of subroutines or an array of labels, 
e.g.,: 

FOR I = 1 TO N 
BEGIN 

IF PROGRAM(I) IN THIS COCKPIT AND FRAME THEN 
BEGIN 

CALL PR.OGRAM(I) or GOTO LABEL(I) 

IF PROGRAM_TIME(I)> PROGRAM_WORST_CASE_ 
TIME(I) THEN PROGRAM_WORST_CASE_ 
TIME(I) = PROGRAM_TIME(I) 

END 

END 

or a CASE statement (see Section 5.4), e.g.: 

FOR I = 1 TO N 
BEGIN 

IF PROGRAM(I) IN THIS COCKPIT AND FRAME THEN 
BEGIN 
DO CASE I 

CALL PROGRAMl 

CALL PROGRAM2 

CALL PROGRAMN 
END 

IF PROGRAM_TIME(I) etc. 
END 

END 

Something like a JOVIAL SWITCH or FORTRAN computed GOTO could 
also be used. In any of these methods, the three task table elements 
other than program address could still be in a table organization. 



5.3,4,2 Operations on Structures 



5. 3. 4. 2. 1 Table Assignment 

As mentioned above, assignment of one table to another of 
corresponding layout is sometimes required. This occurs, for 
example, in assignment of current values of variables to pievious 
pass values, as in the example above from the visibility effects 
program (Box 4 of diagram A3354), In another oxamplr, from the 
Navigation Environment area (Box 2 of T^agram A332), the sequence: 

NUE = FUE 
NVE = FVE 

NSPSHD FSPSI . . 
NCPSHD = FCPSI 
NSINNP = FSTHET 
NCOSNP = FCTHET 
NSINNR ^ FSPI.: 
NCOSNR = FCPHI 
NGALT = FHGZD 
NT AS =: FVPKTS 
NROT = FRA 
NSLEW = SNLSLV/ 
NRESET = UILRF 

represents assignment of a set of "nav freeze" values to a correspond 
ing set of navigation variables, and could be written as one tab^e 
assignment (with greater clarity and less chance of error)-* P.erform- 
ing operations on entire corresponding tables in one statement, e.g. , 

TABLEl TABLE2 -f TABLE3 

indicating addition of all components, would also be useful. 

5.3.4.2.2 Substructure Selection 

Many simulator operations which might use table data for 
clarity._w_o.uid benefit from the ability to perform ope-rations on 
substructures. For example, in the 214A visual system gantry feed- 
back prog* am (Box i of diagram A3352) much ol the data could be 
organized into structures with 3 entries indexable by X, Y, and Z. 
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For example , 



TABLE VGNTRY (X:Z) 5; "gantry data" 
BEGIN 

ITEM VVGMF single fixeij point; "velocity" 

ITEM VVGMI double fixed point; "position" 

ITtJM VVPFB double fixed point; "position feedback" 

END 

could describe much mere clearly a set of data which currently uses 
IS (different identifiers Jn the datapool (two names are used for the 
two halves of the double fixed point values). With such data structures, 
it -;vould be necessary that the X, Y, and Z values of a given compon- 
ent could be treated as a vector in whatever vector operations are 
provided, e.g. , in the above example, the assignment 



VVPFB = VVGMI^'^ 2. 5 

should be possible. 

In another example, from Electrical Systems (diagram A33132), 
comparable operations are frequently performed with 'left' and 'right' 
values* Grouping thi valuej into a table or array with two entries 
inde^ d by "LEFT" and "RIGHT" could allow a single operation to be 
used. For exai. pie, the code used to se^ left and right generator 
relay indicators is: ^ 

LRYGNL = ((EARPML.GT. 40.) .OR. LRYGNL. AND. 

(EARPML . GT. 38. )) . AND, LSGLON . AND. . NOT. 

(EBRYGL.OR. UMLLGF) 
LR GNR = ((EARPMR. GT. 40. ) .OR. LRYGNR.AND. 

(^ARPMR . GT. 38. )) . AND. LSGRON . AND. . NOT. 

(EBRYGR.OR. UMLRGF) 

Combining th^se in a single operation, e.g. , 

M:/GN = ((EAR-PM.GT. 40. .OR. LRYGN .AND. 

(EARPM .GT. 38 j) . AND. LSGON . AND. . NOT. 
(EBRYG.OR. UMLGF) 

could improve understandabiMty and decrease the possibility of 
typographical error. 
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Another instance is the assignment in the Communications 
area (Box 3 of diagram A332) documented by: 

NOllCL = (MPX + NOllIS + N021IS)- ISPRI, 

2 = 2 2 

3 = 3 3 

4 = • 4 4 . . 

- • / * 

This operation, which uses dat.a illustrated in Figure 5-3, uses four 
assignments, one for each cockpit. If the data is in a doubly-indexed 
structure (by operator and cockpit) as proposed in Section 5. Z. 5, this 
assignment might be written: 

NOCL(1,^:0 - (MPX + NOIS(1,^:0 + NOIS(2,^:0) • ISPRI 
5.3.4.3 LFI Structures 

A type of data structure required throughout a simulator is 
that used by Linear Function Interpolation (see Section 5. 2. 2. 2. 2). 
The da.la tables used to represent LFIs consist of tables of break- 
points and tables of values which correspond to the breakpoints. The- 
programs studied employ both single and double variable LFIs. 
Three- variable routines are mentioned but not used. The breakpoint 
table(s) and the value table'^are both defined in the program as lists 
of constants. However, they appear in separate parts of the program 
(separately compiled modules) and are used separately. 

Typically., several different LFI functions might have a 
variable in common, and these variables might have breakpoint lists 
in common. For example, tlie UPT aerodynamics LFIs ^ ee diagram 
A3312): 

FlOO (cx ,M) 
F805 (a, 6 p^,) 
F807 ( a ) 

all have Of as an independent , va riabl e . In F805 and F807 the break- 
point list for a is the same, while FlOO has a different a breakpoint 
list. 

When the value of an LFI variable is first determined 
[e. g. , a above)^ an..''LFI.sea rch'-' routine is called to search for- its 
position in any associated breakpoint lists. The resulting value, 
the interpolant, is used in later processing as a parameter to the 
"LFI value" routine. Thur, one routine uses the breakpoint list and 
one uses the value lir:t. For example, in the UPT aerodynamics sys- 
tem, most breakpoint lookup occurs in the Equations of Motion module 
(Box 5 of diagram A3312), while value computation using these 
breakpoints occurs throughout the system. 
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A double variable LFI is allocated as tWo breakpoint lists, 
X and.Y, and one value list, F{X,Y). The value list is allocated as 
a FORTRAN two-dimensional array would be, with X increasing 
faster. In the UPT simulator, the breakpoints are t^vo-word floating 
point values but the values are one-word fixed point. The value 
lookup subroutine, however, converts the fixed point value to floating 
point before returning it. The reason for this is economy of space, 
and one-word floating point is not available on the UPT computer. 
The nrecision allowed by the sin gle word is adequate for the values. 
In the 214A simulator, which us^es only fixed point, the value tables 
are all sirigle precision; the breakpoint tables are sometimes single 
and sometimes double precision. The altitude'T>reakpoints., for example, 
are double precision. . 

A more readable presentation of LFIs would dictate that the 
breakpoint and value lists be specified together (and thus presumaEPy 
be allocated together).' There appears to be no logical reaspn why 
this could not be done as long as the definition of the structure was 
made available to both routines. A problem in supporting LFI 
representation in-an HOL is that each LFI does not have a unique- 
breakpoint list, but rather several LFIs share lists. (There are, 
of course, unique value lists for each.) It would be wasteful to repeat 
the breakpoint lists, and repeating the lookup process would ^e 
intolerably inefficient. Perhaps the best approach would be'to define 
the lists separately in *a global data base and simply attempt a more 
readable layout which makes associations clearer, e.g. , value lists 
sharing a cornmon breakpoint list could be grouped together under 
the breakpoint list definition; this would not work for double variable 
LFIs, however. 

One simulation HOL study [Coldiez. 1976] gives statistics on 
relative speed of assembly language and FORTRAN LFI routines. The 
FORTRAN programs took almost three times as long. This is 
clearly unacceptable. The author ' s 'comments suggest that the 
FORTRAN code generated was very inefficient because it recomputed 
array subscripts excessively, 

5.3.4.4 Mod elboard Contour Map 

The nio.^t complex data structure observed in the programs 
studied is the "214A Visual System niodelboard contour map (Box 1 of 
dia^rani A3353]. This table gives a maximum elevation indicator 
(a 3-bit value) for every 4-inch square on the modelboard. The actual 
elevation corresponding to the 3-bit value l~s found in an 8-element 
array, to which the 3-bit value is an'index.. Because many 4-inch 
squares will have the sanie elevation value each does not have a 
distinct 3-bit value associated with it. The squares are grouped 
into larger blocks of 5 by 6 -uares (20 x 24 inches). The modelboard 
contains 468 such blocks. C\> y those 20 x 24 blocks which are 'distinct 
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have an associated bit map. A 468-byte vector maps each block 
into the associated bit map. The pi;^ogram allows up to 256 distinct 
blocks. The bit map consists of 6 words, each containing 5 3 -bit value 
thereby covering the 30 4-inch squares in the block. The best data 
structure arrangement for accessing this information would be - 
^omething like: 

i ^ ^ ( 

* ARRAY BLKPTR (0:3«, 0: 1 1 ) B YTE; "indices into BITMAP 

T' for each block" 

TABLE BITMAP (0:255) 6; // 

BEGIN \ 

ARRAY BITARy(0:4, 0:5) bit 3 packed; \ 

END ' ■ . 

The double indexing (for X and Y coordinates) is desirable to support 
calculation of the correct table value - otherwise the program would 
have to compute a single value from the X and Y values. The bit 
map could be represented without too much loss of clarity. as a 
three-dimensional array having dimens'ions (0:255,0:4,0:5). It is 
necessary that the bit values packed. The particular size chosen • 
for the blocks, leading to the 5x6 grouping of bits, is clearly based 
on the word size of the machine (i.e. , 16/3 = 5). Other ^'numbeii-s 
could certainiy^be used, but the decision of what size ol block will be 
optimal miist be based on some knowledge of the particular model- 
board it is clearly not random. 

5. 3. 5 Union Data Type (or Overlays) 

In general, any necessary overlay capability required in 
simulators can be logically provided through the use of structures 
with variant record types, discussed in Section 5, 3.4. 1.4. There 
are instances where overlays might te utilized to obtain a capability 
not explicitly provided by the language, for example accessing 
memory locations by address, as described in Section 5.2.7.2. 
These cases should really be handled in a laanner which makes the 
inten^ more understandable. ^ *' 
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5*4 Contrp-t^S^ructures 

There are rnany instances in the simulators studied in which 
program understandability could be greatly improved through the use 
of modern HOL control structures. In some cases, the program 
documentation ^reflects an awareness- by the programmer that such 
control Structures arc needed, but frequently even the documentation 
does not take advantage of the enhanced readability that would be 
provided. The following subsections present examples of potential 
uses of various control structures in the simulators studied. 

5. 4. i Conditional Control Structures 

5.4.171 IF_THEN_ELSE Control Structures 

V 

Simulation programs contain complex conditional expressions 
controlling the assignment of values to variables™ Any simulation 
language must provide a readable way of writing such assignments." 
The examples in this section illustrate the range of conditional 
assignment control that must be supported by a suitable HOL. 

The programs studied contain numerous examples of complex 
conditional assignments to variables. These are frequently expressed 
in the documentation by multiplying a logical variable or expression 
by the various operands, e, g. , from Flight Controls (Box 1 of 
diagram A33 1): 



X ^ (15.08 FPE =^ WPLAY) + (15.08 - i ERi-B '-''^ WPLAY) - 4. 
Expressed in FORTRAN notation, th s • ./ become: ■ 
X = 15. 08 FPE - 4. 0 

IF (AVPLAY) X = 15.08 - . :iPB ^ 0 ■ 

A better representation, Vv^hich mo ci'.ioc; ^ resembl es the docu- 
mentation, might he the ALGOL-]' :. 

X = 15.08 - (IF WPLAY TK-.':N aPB ELSE FPE) ~ 4. C 

This form might also compile more ^ficiently. 

Another conditiona' expression example is (also fron. 
Flight Controls): 

I'.^ (.NOT. (FELTRU .OR. FELTRD)) GO TO 04 

T EM POO --- 2.25 OTM 

IF (FELTRU) TEMPOO = -TEMPOO 

FTR.iME A?viINl(AMAXl(FTRIME ■■■■ TEMPOO, -8. 0\ 25.0) 




where FELTRU and FELTRD (wliich are fl.-v.j^a indicating ''nose up or 
down") may both be false, but cannot botJi b-^* true. This might be 
expressed using IF— THEN—ELSE, as 

IF (FELTRU OR FELTRD) THFN^ 
BEGIN 

IF FELTRD THEN TEM^^'O = 2.25 ^'^ QTM 

ELSE TEM: -OO -2. 25 QTM . 
FTRIME = AMIN1(AMAX1(FTK1ME TEMPOO, -8.0), 25. 
END 

or, with a conditional expression, as 

IF (FELTRU OR FELTRD; TfiEN FTRIME = 

AMINl(AMAXl(FTRi:/JE QTM ^= riF ?ELTRD THEN 
2. 25 ELSE -2. 25), -^8. v;, 25, 0) 

The 214A Visual Systen^ folvagram A3 V:j has many expressions 
similar to: ' 

VR ^ . 1744 UP - . 1744 ^ DO-^i- 

or, alternatively: 

VR =r , 1744 (UP - DOWN) 

In these cases, UP and DOWN ^xfr-^le bits ip the test box input. 
Both may be off or exactly orr rr,?/.; be on. 

Many of the conditional assignments are documented in 
pseudo-FORTRAN, which ler^.'iS to inconsistent and error-prone 
statemert.s. For example, h om the Communications area (Box 1 
of diagram A332); 

VHAUL ((VHVCL/2) + . 499)) IF LDOPP + (0.0) IF 



(LDOPP- -f -Tv^ u^T + VTUNE) ■ 

Here the test of PAINT and VTUNE serv,es no purpose, but the 
fjc'wchart indicates that the ivient is: 

VHAUL = IF ;NOT LDOPP OR RAINT OR VTUNE) THEN 0. 0 

els::, 'v^hvcl/2 -f . 499 
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Some very comply conditional assignments occur in the 
Navigation Radios area (diagram A3323). Some assignments are so 
complex that both the documentation .and the pseu do- FORT PLAN are 
frequently incomprehensible and often clearly incorrect. An example 
is the description of the setting of variable VGRE: 

VGRE =- (NAVR-VGRI) IF [(VGPWR . OR. .NOT. ERCOT) . AND. 
" • . NOT. FSTER] 

VGRE = (-VGRI) IF [(VGPWR .OR. .NOT. ERCOT) .AND. 

FSTER ■ . 

VGRE = (85-VGRI) IF [( ERCOT . AND. (VGPWR. OR. (ERTII^f^ 

260))) .OR. '.NOT. VGPWR .AND. (ERTIM<260)] ' 
VGRE = (C X . „-K=:=C l//^^^) IF [(ERCOT .AND. (VGPWR. OR. 

(ERTIM > 260))) . OR. .NOT. VGPWR . AND. 
(ERTIM > 260)] 

In this example, the conditiong specified for the four different 
assignments are not mutually exclusive. For example, the set of 
conditions f 



VGPWR, ERCOT, FSTER, (ERTIM > 260) 

satisfies the first, third, and fourth. Examination of the flowcha rts 
suggests that the intent is simply: 

IF VGPWR OR NOT ERCOT 

THEN IF FSTER THEN VGRE = -VCRI; 

ELSE VGRE = NAVR - VGRI: 
ELSE IF ERTIM 1 260 THEN VGRE = 85 - VGRI; 

ELSE VGRE = ^ A^^^^i^K-C C' pj^^; 

One problem that also occurs in the documentation of these 
conditional assi gnments is that' the same logical expres sion appears 
in numerous equations, instead of being tested once preceding them,i.e 

. A - B IF COND C IF NOT COND 



D = E IF COND F IF NOT COND 
G -- H IF COND I IF NOT COND 



instead of: 



IF COND THEN 
BEGIN 
A = B; 

D •- E; 
G = H; 
END 

ELSE 

BEGIN 
A = C; 
D = F; 
G = I; 
END 

If the programmers were actually using FORTRAN rather than 
assembly langxjage, we assume they would not implement this the 
way it is documented., It is not only less clear, but it is in all 
likelihood much less efficient. 

Another instance in which the lack of IF— THEN— ELSE control 
structures has a severe negative impact on readability occur s in the 
following sequence, used to set item LNBUS (from Electrical . 
Systems - diagram A33 1 3 2): 

IF (.NOT. LBUSDC) GO TO 24 
IF (LPWEXT .OR. UQLBSE) GO TO 17 
IF (LBAT .AND. LSWBAT) GO TO 19 
LNBUS = 0. 1 

GO TO 25 , _ 

19 IF (UMLBTY) GO TO 20 
LNBUS = 0. 9 

GO TtD 22 

20 LNBUS = 0. 8 

22 \Y (LRYGNL .OR. LRYGNR) LNBUS = LNBUS + 0. 1 

GO TO 25 
17 LNBUS =1.0 

GO TO 25 , 
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24 LNBUS = 0. 0 

25 IF (EBRYGL .AND. EBRYGR) LNBUS = 0. 5 * LNBT], 

Evidence that this is error-prone may be found in the fact thai the 
logic does not match that in the flowchart for the operation-. A more 
readable representation is: 

IF NOT LBIJSDC THEN LNBUS = 0. 0; 

ELSE IF LPWEXT OR UQLBSE THEN LNBUS = 1.0; 

ELSE IF NOT (LBAT AND LSWBAT) THEN LNBUS = 0. 1 
ELSE BEGIN 

IF UMBLBTY THEN LNBUS =0.8; 

ELSE LNBUS 0. 9 
IF LRYGNL Or'lRYGNR THEN LNBUS 

= LNBUS +0. 1; 
END 

IF EBRYGL AND EBRYGR THEN LNBUS = 0. 5 LNBUS; 

Alternatively, a single assignment of a logical expression to LNBUS 
could be used, < . g. , : 

LNBUS = (IF EBRYGL AND EBRYGR THEN 0. 5 ELSE 1. 0)=:= 
(IF NOT LBUSDC THEN 0. 0 

ELSE IF LPWEXT OR UQLBSE THEN 1.0 

ELSE IF NOT (LBAT AND LSWBAT) THEN 0. 1 
ELSE ((IFUMLBTY THEN 0.8 ELSE 0.9) + 
(IF LRYGNL OR LRYGNR THEN 0. 1 
ELSE 0. 0))) 

The previous example seems more readable, though this one makes 
it clearer that a^ssignment to LNBUS is the intent. 
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Another approach to the description of conditional assignments 
is the decision table. For example, a decision table describing the 
preceding assignment is: 
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5.4.1.2 CASE Control Structures 

Conditional processing corresponding to the CASE construct 
occurs primarily in the simulator support programs (mcnitor, 
debugging, etc.). Instances of this include: 

a foreground task table processing, described in Section 
5. 2. 8 (diagram A312) 

• selection of ftmction based on input parameter by inter- 
computer communications or by background dispatcher 
(see Section 5. 3. 1) 

• transfer based on interrupt number in monitor 
interrupt handlers 

• I/O device routine selection by IOC coordinator 
(currently only one device is connected to this, but the 
program allows for more) (see Section 5.6) 

9 I/O conversion processing based on symbol type in 
Math Model Test (Box 2 of diagram A2) 

% selection of correct function based on function 

select knob in processing Remote Decimal Readout 
Unit (DRU) inputs 
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An interesting type of CASE-like conditional assignment 
occurs in the ground control display program (Box 6 of diagram A35) 
when selecting messages for the instructor. For example, a message 
describing how close the pilot is to the desired glideslope is 
selected as follows: 

-0. 14° <SGTANG <0. 14° "ON GLIDE PATH" 

0. 14° < SGTANC < 0.42° "SLIGHTLY ABOVE GLIDE PATH' 

-0.42° < SGTANG<-j. 14° "SLIGHTLY BELOW GLIDE PATH 

SGTANG > 0,42° . "WELL ABOVE GLIDE PATH" 

SGTANG<-0.42° ' "WELL BELOW GLIDE PATH" 

An HOL representation for this mighl^^ CASE statement with ranges 
(rather than single values) for alternative selection. 

A similar assignment occurs in the Aerodynamics area 
(diagram A3312), here expressed in the "multiplying by Booleans" 
notation: 

X - ((. 1155556%.. 000154074 ='n (X-750. )) (RC . LT. 750. ) 

-f (.1969444+ . 0001085184 =MX-1500. )) - (RC .GE. 750.' ^ 

.AND. RC .LT. 1500.) 
•+ (. 275556 + . 00007861 12 (X-2500. )) ''^ (RC'. GE. 1500. 

.AND. RC . LT. 2500. ) 
+ (. 370833 + . 000635184 (X-4000. )) -'^ (RC . GE. 2500. 
.AND. RC . LT. 4000. ) 

(.4775 + .00005333335 (X-6OOO. )) (RC .GE. 4000. 
.AND. RC '. LT. 6000. ) 
+ (.4775) -r- (RC .GE. 6OOO. ) - ( - 1 . 0) -(FRCIND .LT. 0) 

5.4.2 M ultiprocessing Control 

Multiprocessing is required \n the simulators studied since all 
use more than one CPU. This section describes the overall flew of 
control in the UPT simulator in order to illustrate multiprocessing 
requirements . 

The UPT system uses three CPUs, each of which has private 
memory. There is a-lso common memory accessea by all three. 
The application programs are distributed among *^he three CPUs so 
as to provide the necessary speed of execution. A single application 
program (e. g. , flight) ,;ises only the one CPU to which it is assigned. 
Application programs operate in parallel on the different CPUs,^ but 
do not interact directly with one another. All inter'- -tion and 



sequencing is controlled by the monitor. Necessary synchronization 
between the CPUs is provided by the monitor through the Equations 
of Motion (EOM) Syncing Function, described later in this section. 

Some monitor routines exist in identical form in all three 
CPUs, while others exist in only one. Duplication of a routine 
allows more efficient processing (by eliminating a need for inter- 
CPU communication) and allows the routine to access private 
memory data. A single routine, on the other hand, allows a saving 
of core. In some cases, a single function (e. g. , disk I/O) is per- 
formed partly by a single routine in a master CPU and partly by 
duplicated routines in the other two ^slave' CPUs. For example, 
this organization is used when only one GPU can communicate 
v/ith a particular peripheral. 

Monitor execution begins with system initialization, in which 
the individual CPUs periodically halt themselves and wait for restart 
by another CPU. Upon completion of initialization, the basic execution 
cycle is initiated by a Real Time Clock interrupt in CPUl. (Count- 
down was initiated by the initialization process. ) This interrupt 
causes execution of the Master Timing Routine, which in turn interrupts 
CPUs 2 and 3, passing control to the Slave Timing Routines in these 
CPUs. (The different interrupt levels control the selection of the 
routine to be executed, through a vector of subroutine call instructions. ) 

All three timing routines initiate the foreground dispatchers 
(see Section 5. 2. 8)L by interrupting their respective CPUs. The 
dispatcher calls each of the required simulation programs from its 
task table. Each program returns to the dispatcher when it completes. 
The dispatcher then calls the next required program. After the last 
simulation program completes, the spare time subroutine is called 
to compute the spare time for the cycle. Then the foreground 
dispatcher is exited and the CPU returns to a. wait state until the next 
Real Time Clock interinpt occurs to restart the cycle. (Diagram 
A312 illustrates this sequence'^) 

Other piocesses. such as I/O and background processing, are 
initiated by inrerrupts (either hardware or software triggered) which 
occur asynchronously with the basic cycle. For example, I/O to the 
simulator hardware occurs twice per frame on countdown of the 
Interval Timer, while TTY output, if active, is triggered by the 
120-Hz clock interrupt. 

Communication betv/een CPUs is performed via interrupts or 
via common memory. Data may be comtnunicated through the 
common memory. Control flow is handlf.d by interrupts into one CPU 
triggered by another CPU. For each CPU interface (6 in all), there 
is a word in common memory in which bits are set iiidicating, in 
priority orHer, the functions requested (see Figure/5-5). Thus one 
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CPU requests a function of another by setting a bit in the appropriate 
word and triggering the interrupt. The functions which may be 
requested are: 

o halt - requested if a fatal error or power fril occurs 
in another CPU 

e arm/trigger disk interrupt - used by the slave disk 
handler to indicate to the master that a slave disk 
transfer is complete 

• disk transfer request - sent by the slave disk handler 

to the master when a disk request has been made in the 
slave; sent by the master to the slave when the master 
has completed setup for the transfer 

o TTY/CRT output initiate - sent by IOC coordinator in 
CPUl to a slave TTY/CRT dri;er to grant TTY/CRT 
output privilege 

9 release monitor wait state - sent to release the 

receiving CPU from a wail state; used only during 
initialization, where CPUs are coordinated via wait/ 
release 

e EOM wait freeze - used to release EOM sync wait, 

described below 

Three of h*- se functions are in support of the I/O structure of 
the simulator while three support other control coordination between 
CPUs. As 'halt' is used only for exceptions and 'release' only during 
initialization, only the *EOM wait freeze' function is used during 
regular execution. 

The EOM syncing function is required to keep the simulation 
programs running on the three CPUs properly synchronized. In 
particular, the relationship of the Equations of Motion (EOM) program 
to the flight programs must be kept constant, since EOM inputs are. 
generated in flight. Sinnilarly, the motion primary cues program 
must execute after the EOM program since it uses output from EOM. 
Figure 5-8 illustrates the desired sequencing. Note that the flight 
programs are in CPUS, while the EOM and motion. primary cues 
(MOT^) are in CPUl. The correct order of the EOM and MOT 
programs is assured by their position in the CPUl task table. The 
EOM Sync programs are us.ed to delay the EOM programs until the 
flight programs finish. 
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The CPU3 sync release program immediately follows the 
flight programs in the CPU3 task table. It invokes the inter-CPU 
function listed abce which transfers control to the CPUl sync 
release program. This program computes spare time expended 
while waiting in CPUl, and then terminates the CPUl monitor wait 
state. 

" ^ Prog ram Development Aids 

5.5.1 Com^ile-Time Assignnients 

Values are assigned to identifiers at compile time for two 
purposes — creation of program constants and initialization of pro 
gram variables. This section illustrates the requirements for 
program constants and initialization. 

5. 5. L 1 Constant Definition 

The simulators make use of numerous constants. An HOL 
should allow some method of de-bining identifiers which will have 
constant values, as opposed to the use of ordinary variables for this 
purpose. The constants used are primarily numeric, both fixed and 
floating point. For example, the 214A visual system altitude limit 
program (Box 1 of diagram A3353) uses fixed point constants with 
values of 1/5 and 1/6. The program uses octal constants and must 
describe in comments what they are. An-HOL should permit an 
understandable definition of sucii constan^sj 

In another example from the 214A visual system, the offline 
data verification program, which checks the modelboard contour 
map (Box 1 of diagram A3353), uses four constants preset to model- 
boa rd dimension infor^mation, XSTART, XEND, YSTART, YEND. 
On the first execution of the program, the following initialization 
oc cu rs : 

XLOW = 4^:^CEIL(XSTART/4) 
XHIGH = 4^nFLOOR(XEND/4) 
YLOW ^ 4^:^CEILCYSTART/4) 
.rYHIGH = 4^:^FL00R(YEND/4) 

vThis is an operation which could be more logically done at compile time. 
I\jt compile time e^.pressions a.;-e provided, the relationship between the 
t^'O ?ets of ••alues can still be expressed. 

Most constants used are in large data tables. Examples of this 
are the modelboard contour map (Box 1 of diagram A335 3) and the 
LFI tables, both described in Section 4. A simulation HOL should 
provide a convenient and readable method for establishing such tables 
of constants* 
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5, 5, 1, 2 Variable Ini tializati on 

) ■ — 

Use of compile-time initialization of variables occurs only in 
the offline programs. All initialization of realtime variables is done 
dynamically, None^of the instances noted involve setting of large^^ 
tables of data, 

5, 5, 2 Conditional dbmpilation 

Conditional assembly (compilation) is used in the simulator 
support programs to attain the reusability of one program on several 
CPUs, In some cases, conditional assembly is us"*ed to provide 
variations between the versions. For example, the device codes 
acrtepted by the I/O request handler depend on the CPU, The data 
presetting in the "system description modules"^lso employs conditional 
assembly based on CPU. Conditional assembly is also used in the 
remote digital readout (DRU) program, to adapt the program to its 
X'PU,' (There is a copy in each CPU, ) Its main use is in the code which 
te&ts the CPU select knob to see if that CPU has^ been selected, .V- e, , 
CPU 2 compares the knob value to '2', etc, 

5,5,3 Symbol Dictionary > . 

As discussed in Section 5, 1, 1, the simulators use a global 
data base facility, the ^;ymbol dictionary or "datapool./^ Offline 
programs are pr *viued to support the use of this dictionary^ The basic 
capabilities Oi the data base system include: 

• creation v date, printout, etc, of the symbol 
dictionary ^ i disk file) \ 

o . :"val of mbols defined in the symbol dictionary 

during asser- jly 

• creation, update, printout, etc. of a system cross- 
reference file 

Various error detection capabilities are included in these programs. 
For example, a list of symbols not referenced in any module may be 
printed, 

The offline programs used to create simulator data files 
(e, g, , the malfunction compiler; see Section 5, 3, 2 for a complete 
list) are also sensitive to the symbol diction ry, allowing use of 
program symbols in their inputs. For example, in the malfunction 
compiler (Box 3 of diagram A35), an input expression might be: 

, LEF = ALT(19500/20200)^:-'AIRSP(200/210)iT(50/) 
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indicating: 

"f-urn on malfunction LEF when 19500 < ALT < 20200 and 
200 < AIRSP<210 or T>50" 

The compiler translates this to a binary representation, looking up and 
inserting the location and type information for the datapool symbols 
.LEF, ALT, AIRSP, and T. 

5.5.4 Debugging Support 

The major debugging aids provided to support simulator 
debugging are the remote decimal reaHout unit *)RU) program and 
the Math Model Test program. 



The remote decimal readout unit (DRU) is a peripheral device 
which allows control of the CPUs froT/ remote locations in the simu- 
lator complex. The functions it provides are: 

• reading or setting of any core location in octal, scaled 

fixed point, floating point, or BAMs (Binary Angular 
Measurement) 

o setting of a trap address at which a specified register's 

contents will be printed (on first execution of trap address 
only) 



• display of a selected bit (only) of a selected location 

• halting of all other tasks (i. e. , except the remote 
decimal read'"tut task), and restart 

V 

Figurt 5-9 illustrates the DRU control panel. 



The DRU program mxns as a task in the foreground task table 
(Box 3 oi diagram A312), The program tests the various switch 
settings, etc. and responds accordingly. ^ No I/O is performed in the 
program. The DRU I/O is done in the twi\{e/frame update performed 
by the AST Master Controller (see SectioryS, 6). This program, 
when implementing the Halt function, rpa'Ices itself the only task. 

The Math Model Test program (Box 2 of diagram A2) is an 
offline program used for testing and debugging simulation programs. 
It executes a card stream of input commands, which request such 
functions as: 

I 

• loading a program 

m setting of datapool variables or printout of their values . 
(variables are reference^d by name, values are specified 
or printed accor,ding. to their type as indicated in the 
datapool) 
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e setting or printout of memory'^locations specif ed 

in octal 

• tracing execution 

• timing execution 

• testing of ^ datapool variable to determine whether it is 
within a sj.ecifled tolerance of a specified value; (the 
test occurs v/hen the command is encountered it is 
not a check during execution). 

5.5.5 Onboard Computer Simulation 

A major issue in the TacUcs simulation area is the method 
used to simulate other onboard computer systems (e, g. , avionics, 
stores management, etc. ; see*Boxes»2, 3, and 4 of diagram A334). 
The basic approaches available include; 



o actual use of the onboard computer 

• hardware emulation of the onboard computer 

9 translation of the fliVht softv/are to the simulator 

computer 

s functional modellirE? of ine flight software ou the 

simulator computer 



Combinations of these^approAches arr ilso .^ed. The trade-offs 
involved are discussed in [l8]. This is an o.rea where use of u single 
standard HOL would have a significant impact. 

5.6 ^ I/O • 

This section describ-js the I/O str . trre of the UPT simulator 
to illustrate simulation I/O requiremei^^. 

Through the UPT monitor, application pro^r^^ms are provideo 
access to the following devices; 

• ' disk 

• Aydin CRT 

• TTY/CRT 
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All requests are made through the I/O request handler, using 'a 
parameter table as illustrated in Figvjre 5-4. This request handler 
passes control to the individual device request handler based on the 
TYPE field. Each request handler maintains a request queue, into 
which it links the request. (Actually, the disk handler has two chains, 
high land low priority. ) Other processing depends on device type 
and will be described briefly below. Each CPU has ^an I/O request 
handler, a disk request handler, and a TTY request handler. Only 
CPU2 has an Aydin request handler, and A^din requests are invalid 
in other CPUs. ^ 

The Aydin handler first tests the status of the Aydin device. 
'•Assuming there are no error conditions (in general, errors are 
handled by setting an indicator in the I/O parameter table), the 
request is tested to see if it is a status check, in which case the 
routine returns with the completion bit set in the pa-r^rneter table. 
The status is in a dedicated memory location frorn which it may be 
obtained by the caller. Otherwise the request is ad^ed to the Aydin 
request chain. If it is the only request, it is process^^ immediately 
(by entering in the middle of the interrupt handler). Otherwise, the 
request handler returns and the chained request will be processed 
after an Aydin completion interrupt, 'u^hTei'i-its^turn comes. When a 
request is processed, the appropriate I/O command is constructed 
and initiated. If it is a block transfer, control is then relinquished 
and it will interrupt when complete. Then the completion bit is set y 
in the associated parameter table and the next request on the chain is" 
processed. If the request to be processed is a read of the Aydin 
register, the comixiand is made, and the status repeatedly checked to 
wait for completion since this function does not interrupt when complete. 
Then the completion bit is set in the parameter table and the next 
reque5t is processed. 

The disk I/O process, if in the master disk CPU (#2), proceeds 
similarly to the Aydin I/O process. The processing required, 
however, is more complex. Both direct and indexed files are supported. 
Figure 5-6 illustrates the indexed file structure. The functions 
provided are direct read and write, indexed read (writes must be 
made by treating the file as a direct access file), and extended index 
read (in which two contiguous subfiles of an indexed file may be read 
into different parts of memory in one request). Because of the com- 
plexity of this process, only CPU 2 contains a driver to handle disk 
request chaining, error handling, interrupt servicing, bi^u^ding of 
command words, and indexed file/subfile searches. (CPU 2 was 
selected because it does the most disk I/O. ) CPUs 1 and 3 contain 
slave disk drivers which pass the parameter table to CPU 2, and then ' 
pick up from CPU 2 the command words to initiate the actual block 
transfer. This ..llows a saving of core and processor time in CPUs 1 
and 3. Doing the actual transfer in the 'individual CPU allows the buffer 
used to be in private memory. (Note that the parameter table must 
be in common memory. ) Figure 5-10 illustrates the disk I/O control, 
flow. 
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The TTY/CRT I/O is performed through a device called the 
IOC coordinator. This device controls I/O to any device which uses 
single word/byte transfers exclusively. Although in this configuration 
only the'TTY/CJlT is attached to it, this would also include a card 
reader/punch or line printer. Only teletype output is a callable 
function. It runs as a background task, which is scheduled for the first 
character by the TTY output handler and thereafter whenever an output 
inte.rrupt occurs. The input routine is scheduled when an input 
interrupt occurs. TTY input is used primarily by the de-bug routine, 
v/hic'n ties in directly to the input routine. 

The IOC coordinator itself resides only in CPU 1. Its 'execution 
is triggered by the 120-Hz clock interrupt. (An output request to the 
teletype does not result in immedial" initiation of the output. The 
request is simply added to the chain, tote processed at the clock 
interrupt.) The actual input and output drivers and interrupt h • "lers 
exist in all three CPUs. Figure 5-11 illustrates the TTY I/O rol 
flow. 

Another type of I/O also occurs in the monitor. nis is the 
input and output between the simulator hardware and the data base. 
This transfer is done through a special device called the AST Master 
Controller. This device can perform analog to/from digital conversions 
Figure 5-12 illustrates this system. This I/O is not requested by 
programs. It is performed twice per frame on countdown of the interval 
timer. At 20 msec into the frame, special updates (visual and remote 
decimal readout unit) are made. At 45 msec, normal updates 
(everything) are made. A datapool module contains a collection of 
pointers which define a chain of data to be transferred, and transfer 
of the entire chain is made with a single invocation. Each update 
operation, or transfer, is preceded by the transfer of a test data chain. 
The test data transfer interrupts when complete, allowing verification 
of a successful test. The actual data update does not interrupt on 
completion.. All this occurs in CPU 1. 

5, 7^ Machine Dependency 

Certain types of processing performed in the simulator 
monitors (as in most executives) require low-level, machine - dependent 
code. Examples of these functions are: 

o setting of the system clocks (Real Time Clock, 120-Hz 
Clock, Interval Timer) 

• enabling, disabling, intercepting, and triggering of 
inte r rupts 

• memory protection 
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0 specification of a location for the hardware address 

trap 

• I/O (at the Lowest level) 

It isn't clear how functions such as these can be provided in a machine - 
independent HOL. The traditional solution is to allov/ use of assembly 
language subroutines, possibly expanded inline for efficiency reasons. 
Encapsulation of machine -dependent code is desirable-, in order to 
facilitate reusability. (The UPT monitor uses a macro to perform 
software triggering of . inte r rupts . ) 

Other machine-dependent processing occurs in the debugging 
areas. An example is the Math Model Test (Box 2 of diagram A2) 
trace implementation,. Instructions are not interpreted but are 
execr*"ed with an Execute Memory (EXM) instruction. Prior to the 
EXM, ^n interrupt is enabled so after the instruction is executed, 
control will always return to the trace routine (i, e, , oranches will not 
be taken directly). Registers are recorded so changed registers may 
be printed out. The recorded program counter is used as the address 
for the next EXM, This sort of processing could be done in encapsulated 
assembly language, A mcLchine -independent HOL implementation of 
it seems improbable. 

Another example is the processing of the Remote Decimal 
Readout (DRU) register display trap function, which works as follows: 

a. When trap is request d: 

1. Save indication of which register is requested. 

2. Obtain trap address. 

3/ Extract contents of trap address and save, 

4. Insert at trap address a 'BSL trap routine' 

instruction, defined as a constant in current 
program. (BSL is a subroutine call,) 



5. Exit, 



b. When tra^. address is encountered, the BSL to the trap 
routine is executed, whereupon: 

.. 1. Register contents are saved, 

2. The address following the BSL, which was stored 
by the BSL in the first word of the trap routine, 
is decremented. 
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3. 



The saved previous contents of the trap location 
are restored by an indirect store through the 
first word. 



( 



4. The desired-register is displayed as it was stored 
on entry to this routine. 

' 5. A standard subroutine return, indirect branch 
through the first wotd, now returns J^b the 
interrupted routine to execute starting with the 
trapped instruction. 

This routine is not reentrant since registers are not saved in a stack 
and single memory locations are used for. the various indicators. The 
only implication of this is that instructions within^this routine. may not 
themselves be trapped. HOL subroutine linkage mechanisms would 
not provide this sort of linkage, i.e., decrementing the r-'^turn address 
and using the saved return address as a pointer. 



Section 6 



DETAILED SHOL REQUIREMENTS 
AND LANGUAGE EVALUATIONS 



This Section presents the high-order language (HOL) require- 
ments which should be met by a language for programming flight training 
simulators and evaluates the candidate languages with respect to these 
requirements. The requirements were derived by analyzing the func- 
tional and environmental factors relevant to simulator programming. 

This Section describes the specific simulation language r^qtiire- 
ments determined by our detailed study of the application area a., ccs- 
cribed in Sections 4 and 5, ' It is intended to serve-,as a definitive basis 
for evaluating how well existing program.ming languages could serve in 
programming simulators. The*benefits to be derived from this presen- 
tation of language requirements are these: 

• a. The key implications of our detailed study of programming, 
requirements are presented concisely and rigorously!, 

b. Use of the document as an evaluation guide guarantees 
.that no simulation programming requirements will be 

overlooked, 

c. The document ad'dresses specific SHOL requirements as 
well as general principles which must be considered 
throughout language design or evaluation. 

There is one area of requirements that is not addressed in this 
document exception handling (i, e, , specification of the program action 
to be taken when a routine encounters some condition it is not prepared 
to deal with, e, g. , overflow, time-out, or inconsistencies iti some data 
base). The current state of the art with respect to exception- handling 
language features is quite undeveloped; not much of significance can-be 
said with confidence about what minimal exception handling require- 
ments should be. Moreover, to accurately assess these requirements 
in the simulator area would require a more detailed study of coding and 
design practices than /was possible in this study. Consequently, we 
have chosen to leave requirements specifications open in this area. 

This Section i^ organized with an outline similar to that of the 
IRONMAN [DoD, 1977]. However, the purpose this document/serves is 
somewhat different than the purpose the IRONMAN serves, 'in particular, 
this document addres ses just HOL requirements for design, implerhenting, 
and maintaining flight simulator software as opposed to requirements of all 
embedded computer systems. Consequently we have deleted some IRONMAN, 
requirements that are inapplicable to simulator programming, added others 
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that are consistent with the IRONMAN but more specific, and finaliv 
changed some IRONMAN requirements because they were inappropriate 
l^r the simulator programming environment and application. Another 
Source of differences betv/een this document and the IRONMAN is that 
this document is intended to describe requirements rather than to guide 
a language design effort. Consequently, unlike the IRONMAN, language 
capabilities not specifically required or forbidden may be "provided in 
a language, although it is not expected that such capabilities Will make 
the language more suitable for programming flight simulators. H this 
document were to be used to guide a language design effirt, some 
requirements would be specified in greater detail and some would be 
rephrased to ensurera uniform language. Other modifications would 
depend on whether the design was to proceed by modifying a particular' 
language or was to be created without such constraints. J\ 

Some requirements specified here are considered essential to 
support simulator programming i. e. , a language would have to have all 
these^eatures to be usable in programming all simulator functions. Thetie 
requirements are marked with an asterisk (-). Other ^equirements are 
con|iclered desirable but not essential. These are features recommended 
for Inclusion in any language specifically designed for this applicPtion 
In recommending modifications to the candidate languages t& attain a 
usable SHOL, only the m.arked requirements were judged to be necessary 
Other features, however, were weighed in determining the overall suitablity 
o: the particular language. ' 

Each language requirements section begins with the statement 
of a goal that describes the overall objectives to be met by the SHOL in 
tnat I^uage area. Following the goal are several supporting concepts 
that aid in the attainment of the stated goal. Finall y, toiiowing each 
stated concept are one or more specific language requirements that 
realize that concept. Following each set of requi rements for a particu- 
lar concept, PL/I, JOVIAL J3B and J73I, PASCAL, and FORTRAN are 
discussed y,-ith respect to those requirements. At the end of each section 
languages are ranked according to how well they meet the goal of that section. 

A precise and consistent use of terms has been attempted in 
stating requirements. Potentially ambiguous terms have been defined 
in the text. Care haS been taken to distinguish between requirements 
given as text, and comments about the requirements, given as bracketed 
notes. 

The following terms have been used to indicate where and to 
what degree individual requirements apply; 

^J^^st indicates a required capability to be provided 

IS required by a language or its translator. 
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not required 



not desired 
must not 



need only 



should 



shall attempt 



must require 



must permit 



may 



indicates a language capability that, if present 
in an existing language, need not be used, A. 
language having such a capability is usable for 
simulator programming, but is less desirable 
than a language not having the capability, 

indicates, a language capability that must be 
absent from a language (generally because its 
presence, even if not used, would degrade • 
object code efficiency or the ability of the 
translator to detect program .error s), 

indicates a minimal required capability, A. 
language- providing a more extensive capability 
is acceptable even though the additional capa- 
bility is not -needed in the simulator application, 

indicates a desired goal but one for which there 
is no objecti\5c^ test. 

indicates a desired goal but one that piay not 
be achievable given the current state -of-th^. 
B-Tt, or may be in conflict with other more 
i/.nportant requirements. 

indicates a requirement placed on the user by 
the language and its translators (language is 
subject)^ 

indicates a requirement -placed on the Ijanguage 
to provide an option to the user (language is 
subject), 

indicates a requirement placed on the language 
to provide an option to the user (user is 
subject)^ 



6« 1 General Design Principles 



Goal 



By analyzing the functional and environmental requirisment of 
the simulator application area, the general principles to be observed 
in SHOL design were determined. These principles are to -be followed 
in meeting each of the. specific requirements detailed in subsequent 
sections. 
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software 



lA. Application Suitability . 

The SHOL must support the programming of simulator 



Requirements 



lA.l. The language must provide the functional capa- 
bilities necessary for the production of flight training 
simulation online and support programs, 

lA-2. A language containing only features required by the 
application is considered more desirable than a language 
containing additional features, [The intent is to permit a 
subset of an existing language to be used if it satisfies the ' 
requirements and il use of the subset can be administra- 
tively controlled, ] 

Language Evaluations 

Subsequent sections discuss the degree to which each of 
the languages meets simulator programming require. 

• ments,. The only one of the languages which provides a , 
significant number of unneeded features is PL/I Some 

. of these (e,g., PICTURE attributes.) have no' interaction 
with features which would be used by the simulator pro- 
grammer, while others may require that the programmer 
be aware of them in order to ensure correct use (e, g, . ' 
specifiable lower array bound). Excess capability.' of' 
course, increases translator size and implementation 
cost, and may impact translation speed even if unused, 

IB, Correctness , 

The langua'ge must aid in the development of properly, 
forking programs, * 

'> Requirem ents 

lB-1, The language should avoid error-prone features 
[i,e, . features that are difficult to use correctly] and 
maximize automatic detection of programming errors. 

lB-2, Translators must^produce explanatory diagnostic 
and warning messages, but must not attempt to correct 
programming errd'rs, [Such corrections are seldom 
appropriate and encourage undisciplined programming 
habits, ] 
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lB-3. Thfere must be no lang'ijage restrictions that are 
not enforceable by translators. 

c 

Language Evaluations 

]ach of the languages contains some error-prone con- 
tructs, which are noted. more explicitly in subsequent 
ections. The excess generality of PL/I makes it more 
difficult than the other candidates to learn to use cor- - 
rectly. On the other hand, PL/I provides good facilities 
for error detection at translation and execution time as 
does PASCAL. 

IC. Maintainability r 

As discussed in Section 4. 5, the long lifetime of simulator 
pl-ograms makes ease of maintenance a major design, goal. 

Requirements 

lC-1. The language should emphasize readability over 
writability, [i.e., it should emphasize the clarity,, under- 
standability, and modifiability of programs over pro- 
gramming ease, since programs are usually maintained 
' . by programmers who were not involved in thei-T r-- 
devel|)pment] ,^ ^ * . (^^^ 

lC-2. Explicit specification of programmer intent should 
be possible and be' encouraged [ e. g. , declarations of the 
range of values a variable can have; see 3A-5]. 

lC-3. Defaults should be provided only for instances where 
the default is stated in the language definition, is always 
meaningful, reflects common usagq, and can.be explicitly- 
overridden, 

Langu^age Evaluations 

FORTRAN is the least readable, and hence least main-' 
tainable, of the candidate languages. Specific deficiencies 
(is e. , lack of features supporting readability) are noted 
in the^ following sections. Examples of FORTRAN deficien- 
cies include numeric statement labels (which PASCAL has 
also), implicit declaration s , and limited identifier length. 
The JOVIAL variants (J3B and J73I) are fairly readable, 
though their data declaration statements have a somewhat 
unreadable format. PL/I and PASCAL are probably the 
most readable of the candidates, overall. 
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ID.-^ Efficiency . 



• 'As discussed in. Section 4.4, tHe SHOL must cup'port devel. 
J opment of efficient object programs. • . 

Requirernents 

ID-l. Where possible, features should be chosen to have 
a simple and efficient implementation in many object 
machines, to avoid execution costs for available generality 
where it is not needed, to maximize the number of safe' 
•optimizations available to translators, and to ensure that 
unused and constant portions of programs will not add to 
execution costs. 

lD-2. Unduly complex optimization by translator s should ' 
not be required to obtain efficient ob^j'ect code. 

lD-3. Programmers should be abl« to control time /space 
tradeoffs through appropriate use of language features 
I e.g. , packing directives; see Section 6. 10]. 

Language Evaluation's 

The excess generality of PL/I can affec; object program 
efficiency even if the unneeded features are not used but 
in most cases the impact of such excess generality is only 
on translation efficiency. None of the languages make 
. explicit to the user which features are most costly. 

Section 6. 10 discusses the control provided over time/ 
T^^rr^//^"^^""^ various languages. In general, the 

JUVIAL variants are best in this respect, while FORTRAN 
provides the least capability. 

IE. Simplicity . 

• Simplicity is desired in the SHOL in order to enhance 

readability and to makef the language readily learnable by simulator 
programmers (who are primarily engineers whose experience with 
programming languages is not extensive, generally including only 
assembly language and FORTRAN experience). ^ ^ ■ , 

Requirements 

lE.l. The language should use .familiar notations where 
such use does not conflict with other goals. 

IE. 2. It should have a consistent semantic structure that 
minimizes the number of underlying concepts. ,^ \ 



lE-3. It should be as small as possible, consistent with 
the needs of the application. [See also lA-2. ] 
• 

lE-4. It should have few special cases and should be 
composed from features that are individually simple iw-. 
their semantics. 

IE- 5. The language should have uniform syntactic con- - 
ventions and should not provide several notations for the 
same concept. 

Language Evaluations 

The language which best meets these requirements is 
probably FORTRAN, particularly because simulator pro- 
grammers are. already familiar :ivith It. Also it is a 
relatively "small" language i/e,, it does not contain 
a large number of constructs ojj redundant features, 
PASCAL is also a concise langtiage, but it deviates from 
familiar usages more than any/of the other candidates, . 
PL/I, because of its emphasis' on generality, ^contains 
a large number of constructs Lnd permits many varia- 
tions in notation. j ' 

IF. Implementability. j 

Design of the SHQL must take into account the implementa- 
bility of the language. As difecussed in Section 4. 3, simulation program 
translators have^traditionally been required to operate oxi' machines of. 
modest capacity. 

Re quire nients 

lF-1. The semantics of each feature should be- sufficiently 
well specified and understandable that it will be possible 
to predict its interaction with other features. 

lF-2. To the extent that.it does not interfere with other 
requirements, the language shall facilitate the production 
,of translators that are ^asy to implement. and are efficient 
during translation. [See- also lD-3. ] f 

Language Evaluations 

- As all of the candidate languages have been implemented 
and used, tfieir se.mantics are well understood though not 

. all are well documented. Because PL/Lhas so many 
constructs, there are many interactions between features, 
making the language more difficult to spiscify and imple- 
ment than simpler ones. Its implicit conversion philos- 
ophy compounds this problem. 
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Language Evaluation Summary 



> Because of the general^ and diverse nature of these requirements 

any attempt t(^rank lar^guage s' with respect to them would be inappro- ' 
priate. . Since these general requirements form the basis for the spe. 
cific requirements in subsequent sections, in effect the remainder of 
the evaluation document serves this purpose. 

6.2' General- Svntax 



Goal 



' SHOL syntax-must be selected in keeping with the goals of sim- 
phcity^and maintainability, and with general language design principles. 
Syntactic conventions must encourage the production of readable pro- 
grams and must where possible eliminate opportunities for programmer 



error. 

Supporting Concepts 
2A. Character Set, 



To allow pro-gram portability, all SHOL translators must 
employ the same source character set. and the- character set should be 
widelv suDnortftH 



widely supported 

Requirements 



2A-1. Every construct of the language must have a repre. 
sentation that uses only the 64. character subset of ASCIIt 



!"//$%&'()*+,-./ 
0123456789: ;<=>? 
,@ABCDEFGHIJt:LM}JO 
PQRSTUVWXYZ [ \ ] ^ 



Language Evaluations 



All of the candidate languages except PASCAL and PL/I 
are compatible with 64-character ASCH. PASCAL uses 
the character 'T', and PL/I uses and '| '. PL/I, how- 
ever, is compatible with EBCDIC, as are FORTRAN and 
J3B, but not PASCAL or J73I. 



2B . G ra rti ill I r 



• The SHOi., grammar must contribute to program readability 

and ease of learnihi; language and must make common syntax errors 
easy to detect and cii;:- j. -.ose by translators. 
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2B^ 1. The language must have a free form syntax [i.e. , 
the semantics of constructs should not depend on ^their ' 
position within a line]. ' - ' ^ 

2B-2.'- Multiple occurrences of a language defined syrrtbol 
appearing in the same .'context must, not have essentially. . 
different me^ninjgs, [-For example, the assignment oper- 
ator should be ^differ^nt from the relational equality oper- 
ator; division bf integers yielding an integer result should 
noflDe represented with -the same symbol that yields a 
real re suit. ] . • ^ . ' 

*2B-3. The language -must not permit-unmatched brackets 
of any kind [ e. g. , BEGIN and END must be paired one for 
one] . ^ " 

2B-4. All keyword forms that contain declarations or 
statements must be bracketed that is, must have a 
closing as :weli.as an opening key- word. [This req'uire- 
naent and the previpus one help avoid programmer 'error s 
due to confusion over the lexical extent of the various pro- 
grain constructs.] 

2B-5v • Ther^.must be no control definition facility [i.'e. , 
no means of defining new control structures] . 

2B-6. The structure (i.e., syntax) of expressions must 
not depend on the. types of their operands. [This is, moti- 
vated by a desire for language uniformity.] 

2B-7. The precedence levels (i.e., binding strengths ) -of 
all infix operators must be specified in the langua'ge d'efini 
tion and must not be alterable .by the user. 

2B-8. The precedence levels should be consi stent with 
standard practice. 

( 

Language Evaluations 

Of the candidate languages, only FORTRAN does not have 
a fully free form syntax. 

None of the languages are consistent in always using differ 
ent symbols for different meanings. For example, all but 
PASCAL use the same- symbol for integer and real divi- 
sion. Most also'use compdund statements in a. variety of 
ways in control structures, rather than employing dis- 
tinctive syntax'. 



PL/I, in permitting multiple closure of blocks, pern. its 
unmatched brackets..:? Most of the languages also use 
compound statements to delimit the lexical extent of key- 
words, rather than providing individual closing keywords 
for each. 

None of the languages allow the definition of new control 
structures. None allow the user to alter precedence 
levels of operators. 

All. languages employ a standard set of operator precedence 
levels except for PASCAL, which has only four levels and 
is not consistent with standard practice. 

2C. Mnemonic Identifiers. 

■ ' ■ V t' 

The language must allow the programmer to select 
meaningful and informative identifier names. This is particularly 
important given the large number of identifier^ required in a simulator 
system and the use of these identifier s by groups" of programmers. 

Requirements 

^ ■ ■ ■ ' 

2C-1. Mnemonically significant identifiers [more than 
eight characters long] must be permitted. 

2C-2, There must be a break character for use within 
identifiers, [e.g., the underscore character, as in 
RATE_OF_CLIMB] . 

Language Evaluations '^r 

, . * Ali languages- except FpRTRAN permit identifiers of more 

than eight characters, 'All except PASCAL allow a break 
. character in identifiers." 

2D, Static Typing. 

In keeping with general language design principles and in 
support of program maintainability and efficiency, the types of values 
must be determinable from the source program. * 

Requirements 

2D-1, The value type of each variable, array or record 
component, expression, parameter , and' function re suit * 
must be determinable at translation time, .^f^i value type 
specifies the set of values associated wim a program 
elert^ent. "Type'' is used in this document to mean value ' 
type.] 



^2D-2, There mufet be no implicit conversions between 
value types explicit conversion operations shall be 
provided. 

2D-.3, A reference to an identifier that is not declared in 
the most local scope mtist refer to a program' element that 
is lexically; global',, rather than to one that is global through 
the dynamic calling structure, [This is the normal block 
. structure scoping -rule . ] • 

Language Evaluations 

■ Most value -types are determinable at translatron time in all 
of the languages. The. only exceptions involve the attrib- 
• ■ ^ utes.of formal procedure parameters. Only J73I requires' 
a specificatidn of parameter attributes of such procedure 
parameters, arid only J-73I and PASCAL require specifica- 
tion of their result attributes. (J3B §pes not allow pro- 
cedur.e parameters.) --^ 

o . Inhplicit conversion is prevalent in PL/I, and, to a lesser 
^ extent, in 'J73I. There is little in FORTRAN, J3B, and 
PASCAL. In general, it is restricted in these languages 
to conversions between integer and real types. PASCAL 
allows implicit conversion only of integers in assignment 
to reals. Most of the languages restricting- implicit con- 
version, however, do not provide all of the explicit con- 
ver-sion operations which might be necessary. For 
example, only PL/I provides explicit conversion from 
numeric types to^'character strings. 

As required all the languages bind free names statically 
rather than dynamically. 

2E. Comments 

The SHOL must provide a comment facility that is easy to 
use, 5;o commenting^ is encouraged. The comm^ent facility should allow 
comments to be used with maximum readability. 

Requirements 

2E-1. The language must allow comments to be embedded 
within program text [ e.'g. , a comment bracketed by special 
left and right bracket 'symbols, and preceded and followed 
by program te^t on the same line, or a comment termi-- 
nated by end of line] . 



2E-2, Bracket symbols must be short no more than two 
characters. 



. Language Evaluatipns 

Of the cand'idaCe languages, only FORTRAN' does not pro- 
vide the require'a^flexibility in comment, placement. " All 
languages provide short comment bracketing symbols. 

Lang uage Evaluation Summary - . . ' ' 

. ^^^^ X ^ , 

The candidate languages are ordered, according to .the degfee to 
v/hich they meet SHO'L general syntax requirements, as follows: 

* 

J3B- Most of the requirement's are met. 

Deficiencies are: 

• , use of same^symbol. for different meanings 
■> : ' • lack of closing ke ywords. ^ 

• lack of explicit conversion operations 

J73I. Most requirements ar£ met. Implicit conversions 

'can oc'cur. 

Deficiencies are: 

• ' use of same symbol for cliffere.nt meanings 

• ' lack of closing keywords 

• implicit conversions 

• lack of explicit conversion operations 

PASCAL- Is not ASCII cpmpat.i]ble. Operator precedence levels 
are non-standard. ' 

Deficiencies are: 

use of same syrr)bpl for different meamrips 

• . lack of closing ke ywords 

• not ASCII compatible 

• non-standard precedence levels 

• no break <;haractei> in identifier 

** ' ■ > 

I. • lack of explicit conversion operation's 



FORTRAN- . Comment facility and statement formatting are 
inflexible. Mnemonically significant identifiers 
are not permitted. 



Deficiejncies are: 

• n^ not free format 

• use of same symbol for different meanings 

• identifier length too .restricted 

• comment placement inflexible 

• -^^ . * 

PL/I- .. Is not ASCII compatible. Multiple closure and 

implicit conversions are permitted. 

Deficiencies are: 

• not ASCII compatible 

• use of same symbol for different meanings ' 
• • multiple closure 

• implicit conversions 

6. 3 Data Types 
Goal 

The SHOL must provide the value types required to represent 
simulator data, must suppor efficient processing with them, and must 
allow them to be used in a jadable and understandable manner. Nota- 
tion for and support of the various types should be consistent between 
types and whenever possible should correspond to. common practice. 

6. 3, 1 Numeric Types 

Goal 

The language must support integer and real (both fixed and float) 
numeric types. Uses of numeric data in simulator programming are 
discussed in Sections 5. 2. 1 and 5. 2. 2. The SHOL. mus^t allow the pro- 
grammer to use the various real number representations available on 
the target computer. Requirements for this are discussed in Section 
5. 2. 2. 1 and in Section 4. 2. 



Supporting Concepts 



3A. » Numeric Type Definitions . 

Integer, fixed, and floating point types, with prpgramme3r ♦ 
control over precision, must be provided. Representations should cor- 
respond- to standard usage. 

Requir ements 

-3A-.1. The language must provide types for integer, fixed 
point, and floating fioint numbers. [See Sections 5.2 1 
and 5.2.2.] ^ 

3A-.2. The minimum accuracy of each floating point vari- 
able [e. g. , number of decimal digits] and the minimum 
accuracy of each fixed point variable [e. g. , maximum 
value of the least significant bit] must be specified in 
programs. 

3A-.3. Such accuracy specifications must be interpreted 
as the minimum, accuracy to be supported by an imple- 
mentation it is sufficient for implemented fixed point 
accuracies to be limited to powers of two. 

'J^*3A-4. Various sizes of real number representations are 
required. [Section 5. 2. 2. 1 discusses the use of both 
single and double word representations to allow Accuracy 
vs. space tradeoffs. ] 

3A..5. Declarations of the range of numeric variables must 
be optional (see also Section 6. 10), and need Qnly be speci- 
fied with constant values.^. [Range specifications make 
programs more unde r standable and can improve object 
pode optimization, but there is insufficient experience 
with their use to make range declarations mandatory. 
Range declarations may also be used to specify (implic- 
itly) the minimum number of bits occupied by fixed point 
values. ] ' 

Language Evaluations 

Of the candidate languages, only J3B and PL/I provide 
both fixed and floating point real number' types. Only J73I 
and PL/I allow specification of floating point accuracy. 
PL/I allows specification in decimal digits, while J73I 
requires specification ■ iji bits. In neither case is the inter- 
pretation pf the accuracy implementation dependent. Only 
PL/I allows specification of fixed point accuracy. Again, 
accuracy maybe specified in decimal digits, and inter, 
pretation* is not implementation dependent. 
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Progrannmers may select various sizes of real number 
representations in all of the languages except PASCAL 
and J3B (for fixed point). PL,/I and J73I allow explicit 
.specification of the size. None of the languages allow 
explicit declaration of read variable ranges. 

3B., Numefic Literals. 



The SHOL rnust allow the pr ograd^m^er to specify numeric 
literals (i. e. , numbers of the form 1, 5.6, etc.'') in a readable and 
consistent manner. 

Requireme nts 

'-3B-1. Numeric literals are required. [See Section 5.Z.] 

3B-2. Ernbedded spaces must be permitted in real literals 
[These would enhance readability in the long literals occa- 
sionally Used in simulator programming, a^'sNin the example 
in Section 5. 4. 1- 2. ] 

3B-3. Nutn eric literals must have the same value in uro- 
grams as in data. [i.e. , literal values input during pro- 
gram execution shall have the same value as if they had 
been processed by the translator. ] 

Language Evaluations 

All of the candidate languages provide numeric literals 
for both integer and real type*.. Only FORTRAN .permits 
en Redded spaces. 'None of the languages appear to 
require that program and data^'literals convert 
equiyalently. 

3C. Numeric Operations . 

The language must provide a uniform set of the basic arith 
metic and comparison operations for numeric types. Trigonometric 
operations must also he supported. Section 5. 2, 2. 2 discusses simu- 
lator requirements for numeric operations. 

Requirements 

3C-1. There tnust be operations [ i. e. , "functions] for con 
version between numeric value types and for conversion 
from other types (e. g. , character, bit string) to numeric 
types. [ See Section 4. 5. ] 
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*3C-2. There must be operations for addition, subtraction, 
multiplication, division with real [fixed point and floating ' 
point] result, and negation for all numeric value f-yoes 
[See Section 5. 2. ] . -XP • 

3C.3, There must be operations for integer and fixed 
point division with integer result and remainder. [A ^ 
particular requirement for this occurs in the camera/ 
modelboard visual systems, for locating modelboard 
positions, as discussed in Section 5. 3. 4. 4, ] 

3C-4. There must be operations for spe'^ifying the accuracy 
of fixed and floating point addition, subtraction, multiplica. 
tion, and division results. j 

3C-5. Default scaling rules for fixed point operations need 
not produce results more accurate than the accuracy (i.e., 
scale) of the least accurate operand, [ e. g, , 1, 1+20, 01 
may yield 21.1,] 

3C-6. Absolute value and max/min functions (allowing 
more than two arguments) must be provided for all num. -i- 
value types, [ See Section 5, 2, 2, 2,3,] 

3C-7, For real value types, square root and trigonometric 
functions are required. [Trigonometric functions are used 
in analog I/O handling and in various display-related 
programs such as the map plate compiler; see Section 
5. 2, 2. 2, 1. ] . 

-3C.8, There must be equality [ i. e, , equal and unequal] 
and ordering operations [i.e., less than, greater than, 
less or equal, and greater or equal] between elements of' ' 
each numeric value type; [see Section 5. 4..1-. l]. 

3C^9. There must be a means of explicitly te stinV whether 
a numeric value is within a given range [ e. g. , the ^hained 
comparison; see Section 5.4. 1,2.},. 

3C^10, Numeric values must be considered equal if and 
only if they represent exactly the same abstract value. 
[ i. e. , accuracy specifications must not be taken into 
account in testing for equality; otherwi.se ArB and B^C 
does not imply A=:C. ] 

Language Evaluations 

All of the languages allow explicit conversion^ from real to 
integer types, and'all except PASCAL from integer to real. 
Of the languages providing more than one real representa- 
tion, all but J3B provide representational conversions, 
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Only PL/I provides all desired conversions from other 
types, but J73I and J3B provide some support. 

All of the languages provide the basic arithmetic opera- 
tions required, but only PL/I provides accuracy-defining 
specifications for their results. Of the numeric functions 
required, only FORTRAN and PL/I provide max/min func- 
tions, and only FORTRAN, PL/I and PASCAL provide 
square root and trigonometric functions. (PL/I provides 
more trigonometric capability. ) All languages have an 
absolute value function. 

All of the languages have numeric relational operations 
required, but none have a capability for range testing, such 
as chained comparisons. In all of the languages, numeric 
compai^isons are exact. 

Language Evaluation Summar y 

The candidate languages srt.e ordered, according to the degree to 
which they meet SHOL numeric da'ta type requirements, as follows: 

PL/I- Most major requirements are met. 

Deficiencies are: 

e accuracy specifications are implementation 
dependent 

• no ran^ge specifications 

• no embedded spaces in literals 

© program and data literals not required to 
convert ^quivalently 

\ 9 no chained comparisons 

J3B- Control over numeric accuracy is inadequate. Not 

all desired arithmetic operations are provided. 

Deficiencies are: 

» no conversions from character or bit to real 

• no accuracy specifications 
3 no range specifications 

• no embedded spaces in literals ^ 
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• ' program and data literals not required to con- 

vert equivalently 

• no real representational conversions 

• no accuracy-defining specifications for results 
of computations < ^ 

• no max/min, square root, or trigonometric 
functions ^ 

• no chained comparisons 

Fixed point real numbers are not provided. Most 
other requirements^ are met. 

Deficiencies are: 

• .no conversions from other types to numeric 
type s 

o no fixed point reals 

» no accuracy specifications 

€> no range specifications 

• program and data literals not required to con- 
vert 'equivalently { 

• no accuracy-defining specifications for results 
of computations 

• no chained comparisons 

Fixed point real numbers are not provided. Not all 
desired arithmetic operations are provided. 

Deficiencies are: 

• no fixed point reals 

• accuracy specifications implementation 
independent 

• no range specifications 

• no embedded spaces in literals 



• program and data literals not required to con- 
vert equivalently 

• no accuracy-defining specifications for results 
of computations 

• max/min, square ropt., or trigonometric 
functions 

• " • • no chained comparisons 

PASCAL- Fixed point real numbers are not provided. Many 
required accuracy* controls, conversions, and 
. numeric operations are not provided. 

Deficiencies are: 

• no conversions from other; types to numeric 
types . 

© no fixed point reals 

• no accuracy specifications 

• no control over size of real number 
representations 

• no range specifications 

• no embedded spaces in literals 

• program and data literals not required to con- 
vert equivalently 

• no integer to real conversions 

m no accuracy-defining specifications for results 
of computations 

• no max/min functions 

• - no chained comparisons 

6.3.2 Enumeration Types ^ . 

Goal ' V 

The SKOL must provide a status, or enumeration, data type. As 
discussed in Section 5.2.3, use of enumeration types to represent flags, 
case alternatives, and array indices would greatly enhance program 
unde rs^tand ability. 
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Supporting Concepts 
3D, Enumeration Type Definitions , 

Enumeration types are required for program readability. 
Requirements 

jr 

-3D-1. There must be value types that are definable in pro- 
grams by ordered enumeration of their elements [e.g., 
type angle = (phi, psi, theta)] . 

Lang uage Evaluations ' 

. ' ^ i 

Of the candidate languages, only J73I and PASCAL provide 
enumeration types. The J73I forhi is rudimentary 
. Essentially a sequence of integer s'with names. There are 
no enumeration variables in J73L ^' 

3E. Enumeration Literals, r 

Enumeration values should be expressible in a rea'dable and 
natural manner. 

Requirements ' - 

3E-1. The elements of an Numeration type maybe 
identifiers, 

• / 

3E-2, ^numeration value names of different enumeration 
types^must be permitted to be -identical, ' . 

Language Evaluations 

In J73I, enumeration literals are lexically distinct from 
identifiers, J73I allows duplicate enumeration names in 
different lists, while PASCAL does not. 

3F, Enumeration Operations, 

Operations provided for enumeration types must allow their 
use as flags, case alternatives, and array indices. 

Requirements 

-3F-1. There must be at least equality and inequality oper- 
ations between elements of enumeration types. [This is 
to ensure uniformity; equality should be an operation 
defined for all types,'] , 
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*3F-2. There must jDe successor and predecei^pr opera- 
tions on ^ach enumeration type. [i.e. , operations pro- * 
ducing the next and^receding elements of ah enumeration 

Vtype's value set; these operations are inherent in the 
notion of an enumeration type.] 

Language Evaluations . 

Both J73I and PASCAL .support equality knd inequality oper- 
ations on enumeration types. Only PASCAL" provides 
successor anci predecessor operations. 

Language Evalu ation Summ'^ry 

: ^' — . 

The candidate lang-uages are ordered, according to the degree to 
which they meet SHOL enumeration data type requirements, as follows: 

PASCAL- The basic requirements are met. 

Deficiencies are: 

• duplicate names may not be used 
J731- The capability provided is rudimentary. 

^ Deficiencies are: 

• no enumeration variables 

• literals are lexically distinct from ictentifiers 

• no successor and predecessor operations 



' r 

J3B, ^ ^ 

FORTRAN, • .-^ * -^ e 

PL/I- Enumeration types are not provided. 

6.3.3 Boolean Type 
.Goaj 

Th^'SHOL must provide a Boolean data type. As noted in Section 
5.2.5, Boolean data. is heavily used in simulators, particularly in the 
Navigation and Communications area. 

*} . ■ 

Supporting Conce pts 

3G. Boolean Type Definitions. 



The Boolean data type facility in the SHOL should contribute 
to program readability and allow programs to be structured more clearly. 



Require ments 

*3G- 1. A Boolean data type is required [ see Section 5. 2. 5] . 

3G-2. Boolean expressions must be evaluated in short- 
circuit mode [e.g. , A OR B must not cause the evaluation 
of B if A is true] . 

Language Evaluations 

Only FORTRAN and PASCAL support an actual Boolean 
data type. The other languages u^e bit strings of length one. 
, Only FORTRAN requires short-ci'rcuit evaluation of 
Boolean expressions. (This is not specified in PASCAL.] 



: 3H. Boolean Literals, 
variables. 



A useful Boolean facility requires literals as well as 



Require ments 

-3H.r. Boolean literals (TRUE and FALSE) are required. 
Language Evaluations 



Both FORTRAN and PASCAL have TRUE and FA{LSE lit- 
erals. J3B provides built-in constant names TRUE and 
FALSE for- the bit strings »1» and '0' 

31. Boolean Operations . 

The standard Boolean operations mus.t be provided in a 
uniform manner. 

Requirements 

-31-1. There must be operations for conjunction, inclusive 
disjunction, and negation (i.e., AND, OR, and NOT) of 
Boolean value types. [These are the most frequently used 
Boolean operations; see Section 5. 2. 5. ] 

-31-2. There must be equality and inequality [i. e.\ exclu- 
sive or] operations for Boolean types. [The operations 
are required for uniformity. ] 

Language Evaluations 

, ^' Both FORTRAN and PASCAL provide the desired 

y qperations. 



109 



Language Evalua<:ion Summary 

The candidate languages are ordered, according to the degree to 
which they meet SHOL Boolean data type requirements, as follows: 

•FORTRAN, - ' . 

PASCAL- All desired capabilities are provided. 

J3B, There is no' Boolean data type (J3B does/provide 

J73I, PL/I- TRUE ^nd FALSE bit string Hterals). 

6. 3. 4 Character Type / 

' ' ' / 

Goal , ( . . ^ • 

The SHOL must provide a character data type arid associated 
character operations to support instructor display programs and offline 
simulation support programs. Simulator character handling require- 
ments are discusf^ed in Section 5.2.6. 

Supporting Concepfa[s * 

3J. Character Type Definition s > T 

^ The character data type should be supplied in a manner 
which contributes to program efficiency, and should not allow excess 
generality not required by the application. The feature should be natural 
and easy to use. 

Requirements 

^'3J-1. A fixed length character string data type is required 
[as opposed to representing strings as arrays of charac-" 
ters; a separate data type is needed to promote program 
understandability] . 

3J-2. Explicit specification of string length i^ required, 
and the length must be specified with a constant value. 
[Only use of fixed length character strings was observed.] 

'I'SJ-S. It must be possible for the programmer to define 
^ new character sets. [Some simulator peripherals require 
character sets other than the built-in ASCII.] 

Language Evaluations 

All of the candidate languages except FORTRAN provide a 
character data type. In PASCAL, however, character 
strings are represented as arrays of single characters. 

I 4. J 
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Neither PL/I nor J73I .require explicit specification of 
string length, and PL /I permits strings of non^constant 
length. 

None of the candidate languages support the explicit defini- 
tion of new character sets. 

3K. Character Literals . \ 

A character literal facility allowing representation of 
character constants for the various simulator peripherals" i s necessary. 

Requirements 

>'3K-1. Fixed length character string literals are required.. 

^'=3K-2. The character code used for^'a literal must be . 
programmer-definable.. [This is necessary to support 
the concept of definable new character sets.] 

*3K-3. It should be possible to include unprintable charac- 
ters in string literals. [Formatting codes in strings for 
visual displays are an example of the kind of unprintable 
characters needed here.] 

Language Evaluations 

All of the candidate languages (including FORTRAN) pro- 
. vide character string literals. None allow the programmer 
to define the character code used. Only PL/land J731 
supports the inclusion of unprintable characters^ 

3L. Character Operations . 

Character operations provided in the SHOL must support 
the types o'f character processing performed in simulators, which are 
primarily display formatting and offline data file compilation. • 

Require ments 

=«->3L-l. There must be operations for substring extraction 
. and assignment (the substring length mu^st not be restricted 
. ' to a constant value), access to string length', string replica- 
tion by aconstant factor, and -location of a given sub-' 
string within a string (i.e., INDEX) [-see Section 5.2.6. l]. 

-3L-Z. Equality and inequality must be defined on character 
types. 
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3L.3. Ordering operations must be defined on the built-in 
character set. 

''^3L-4, There must be operations for conversion from other 
types (e.g., numeric, BooleanV'to character type. [These 
operation's are required for completeness; it should be 
possible to obtain a printable representation of a built-in • 
type-] . ^ 

Language Evaluations 



Substring extraction and assignment is provided by J3B , 
• J73i; and PL/I, Only,J73 1 and PL/I allow access to 
string length, and only ^PL/I supports string replication 
and substring location. Only PL/I provides conversiori^ 
from other types to character. 
c> ■ • • 

r:' ' AH of the languages (except FORTRAN) support equality 

and inequality operations on character types, and all 
\ b'ut J3B provide ordering operations. 

Language Evaluation Summary 
^ ^ ^— — 

The candidate languages are ordered, according to the degre^ 
to which they meet SHOL character data- type requirements, as follows: 

_ PL/I- Most desired functions are provided. Excess 

capability is supported. 

Deficiencies are: " 

• explicit length specification not required 

• non-constant length specification allowed 
definition of new character sets not supported 

Fewer of the desired functions are prc^\'ided. 
Deficiencies are: 

• explicit length specification not required 

• definition of new character sets not supported 

• no string replicr.tion or-3]Lil:r3-trriTrg--lo.c^ation 

• no conversion from other types to character 
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J3B- 



PASCAL. 



FORTRAN. 



Fewer desired functions are p'rov.ided. 

.* • 
Deficiencies are: 

• definition of^new character sets not supported 

• no inclusion of unprintable characters in 
literals . 

• ■ no access to s^tring. length, string repli cation , 

or substring location 

• . no- ordering operations 

• no conversion from othex types to character 

Strings are supported as arrays, Few of the 
desired; functions are provided. 

Deficiencies are: 

V- ... 

• strings represented as. arrays ■ * 

• definition of new characver sets not supported 

• no substring extraction or assignment, access 
to 'string length, string replication, or sub- 
string location 

• no conversion from other types to character 
There is little support for character data, \^ 
Deficiencies are: ^ 

no character data type 
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no inclusion of unprintable characters in 
literals 

no string operations or relations 

no conversion froro^other type^s to character 



6. 3. 5 Bit String Type 
Goal 



ations, 



The SHOL must provide a bit string data type and asso^ciated oper. 
These are required in simulator programming fo/ manipulating 
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I/O values and for representing vectors of Booleans such as the frame 
and cockpit masks and the malfunction indicator vector. Sections 5.2.4 
and 5. 3. 1 discusses uses of bit string data. 

Supportting Concepts 

3M. Bit String Type Definitions. 



The bit string data^type should be natural and easy to use 
and should allow efficient implerhentation. 

Requirements 

i 

'-3M^1> (A bit string data type is required [see Sections 
5.2.4 apd 5.3. l] . 

3M.2. Explicit specification of bit string length is required 
and must be specified with a constant value, [No use of 
varying length bit strings was observed. ] 

Language Evaluations 

Bit strings are provided in J3B, J73I, and PL/I. Neither 
PL/I nor J73I require explicit length specification. Pl7/I 
allows strings of non-constant length. (PASCAL provide s 
a capability similar to bit strings with the set data type. ) 

Bit/String Literals . 

There must be a natural notation for specifying bit string 



Requirements 
-3N-1. Fixed length bit string literals are required. 

3N«2. - Literals must be specifiable in bases 2, 8 atvi 16. 
[Examples of literals in all these bases have been 
ob se rved. ] ' ^ 

Language Evaluations " 

All three languages which support a bit string data type 
provide bit string literals. PL/I allows specification only 
in base 2, J3B allows only base 16, while J73I allows all 
three. 



3N. 
literals. 
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The operations provided for bit strings must suppart the 
construction and decomposition of_.s.trings representing I/O values, as 
well as the masking and shifting of strings representing indicator 
vectors. 

Requirements 

''^30-l. There must be operations for bit-by-bit conjunc- 
tion, inclusive disjunction; exclusive disjunction, and 
negation [AND, OR, XOR, and NOT] defined for bit 
strings. [These are the normal bit string operations.] 

''^30-2. There must be operations for substring extraction 
and assignment (the s ubstr in g length must not be 
restricted to a constant value), access to string length, 
string replication by a constant factor, and location of 
a given substring within a string (i. e. , INDEX). , [ A use 
of bit string extraction is^/' discussed in Section 5. 2. 4. ] 

'^30-3, Equality and inequality must be defined on bit 
string, type s. 

30-4. There must be operations for left and right 
shifting of bit strings. 

30-5. There must be operations for conversion from 
other types (e. g. , numeric) to bit string type. [Accessing 
the representation of a value is necessary in I/O and other 
conversions. ] 

Language Evaluations 

All three languages which support bit string provide AND, 
OR, and NOT operations. All provide the desired conver- 
sion operations. PL/I does not provide XOR, while J3B 
and J73I do. All three provide substring extraction and 
assignment, J73I and PL/I provide access to string length, 
and only PL/I supports string replication and substring 
location. Shift operations are provided only in J3B and 
J73L 

Only J73I and PL/I support equality and inequality 
ope ration s . 



1:: 

115 



Language Evaluation Summary 

The candidate languages are ordered, according to the degree to 
which chey meet SHOL bit string data type requirements, as follows: 



J73I. 



J3B. 



PL/I- 



PASCAL- 



Most requirements are met. 
Deficiencies are: 

• explicit length specification not required 

• no string replication or substring location 
Fewer capabilities are provided. 

Defi ciencies are: 

• no base 2 or 8 literals 

o no access to string length, string replication, 
or substring location 

• no equality/inequality operations 
Several desired capabilities are not provided. 
Excess capabilities are supported. 
Deficiencies are: 

• explicit length specifiction not required 

• non-constant length strings permitted 
no base 8 or 16 literals 

» no XOR or shift operati-ons 

Some similar capabilities are provided by the set 
data type. 



FORTRAN- Bit^strings are not supported. 
6. 3. 6 Pointer Type 
Goal 

A pointer data type (see Section 5. 2. 7) is needed to support 
certain types of processing performed in simulator executives (e. g. , 
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I/O request queues) and for use with dvoiamically allocated storage, 
which might be required in a digital image generation visual system 
The facility provided should meet these requirements without providing 
excess generality at the expense of efficiency. 

Supporting Concepts 

3P> Pointer Type Definitions . 

The pointer data type must be provided in a manner con- 
sistent with the static typing of the SHOL, thereby supporting program 
maintainability and reducing opportunity for error. 

Require ments 

3P-1. A pointer data type is required. 

3P-2. Explicit specification of the type pointed to must be 
required for each pointer definition. 

3P-3. Explicit dereferenfcing of the pointed-to value shall 
be required. [Dereferencing is the operation of accessing 
the object pointed to by a pointer value, e. in 
PL/I, PT.A in PASCAL, or A(P) in J3B. Requiring 
explicit dereferencing contributes to program understand- 
ability. J 

•••3P-4. It must be possible to define objects which are 
dynamically allocated. [See 3R-1 below. ] 

Language Evaluation s 

A pointer data type is provided by all of the candidate 
languages except FORTRAN. PASCAL pointer definitions 
do not specify the type pointed to, and in J3B such speci- 
fication is permitted but not required. The only languages 
which require explicit dereferencing are J3B and PASCAL 
though it is available in J73I and PL/I also. 

Only PL /I and PASCAL support dynamic allocation of data 
objects. 

(Note that J73I pointers are declared and represented as 
integers. There is not an actual pointer type.) 

3Q. Pointer Literals. 

The concept of a null pointer must be repre sentable in a 
distinctive and readable manner. Pointer constants specifying addresses 
of data objects are also^ required by the uses of pointers in simulator 
executives [see 3R-3J. 
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^ Requirements 

3Q-1. There shall be a NULL pointer literal. [This is the 
literal normally provided for pointer types.] 

1 ■ 

Language Evaluations 

r 

Of the languages supporting pointers, only J73I does not ^ 
provide a NULL pointer literal. 

3R. Pointer Operations . 

Pointer operations supporting simula'toir requirements, as 
discussed in Section 5.2.7, must be provided in a manner compatible 
with the goal of object code efficiency. 

Requirements * . 

^'^SR-l.- Ther6 must be-'operations for the allocation and 
deallocation of dynamic storage. [Explicit deallocation is. 
required as bpposed to garbage collection, because of the 
negative impact of garbage^ collection on efficiency.] 

3R-2. Identity and non-identity relations must be defined 
on pointer types. •:[ These are the equality operations for 
the pointer type.] 

^'3R-3. There must be an operation for converting from 
integer to pointer values. A program using this operation 
o must be flagged by the translator, so use of this capability 
can be administratively controlled. [This capability is 
needed to provide some SHOL support software, as 
described in Section 5.2.7. Since its use can impair pro- 
gram understandability, its use should be highlighted. 
Such highlighting would not be possible if the capability 
were provided by an assembly language subroutine (see 
IOC).] 

Language Evaluations 



Only PASCAL and PL/I provide operations for allocation 
and deallocation of dynamic: storage. 

All of the languages which Iv.ive pointers except J73I pro- 
vide identity/non-identity operations. (J73I simply uses 
integers as pointers, so , relational operators are available. ) 

None of the languages support ..explicit conversion from 
integer to pointer. (In J73I, since pointers are integers, 
the desired capability is, in a sense, provided.) 
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Language Evaluation Summary 1 

The candidate languages are ordered, according to the degree to 
hich they meet SHOL pointer data type requirements, as follows: 



PL/I- 



Pa'^CAL. 



J3B- 



J73I. 



FORTRAN. 



Most requirements are met. 
Deficiencies are: 

• explicit dereferencing not required 

• no. conversion from integer to pointer 

y 

Most requirements are met. Pointers are not 
bound to a tj^pe. 

Deficiencies are: 

• pointer definitions do not specify the type' 
pointed to 

• no conversion from integer to pointer 

No dynamically allocated data objects are provided. 
Deficiencies are: 

• specification of type pointed to not required 

• no dynamically allocated objects 

• no conversion, from integer to pointers 

Pointers are really integers. Dynamically allocated 
objects are not provided. 

Deficiencies are: 

• pointers are integers 

• explicit dereferencing not required 

• no dynamically allocated objects 

• no NULL literal 

There is no support of pointer data. 
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6. 3. 7 Procedure Types 



Goal y 

The SHOL must provide procedure variables in order to support 
current methods of foreground task dispatching," as described in Section 
5. 2. 8, This feature rnust be provided in a manner that does not increase 
the likelihood of programmer error nor add unneeded complexity to the 
language, ' - 

Supporting Concepts 

3S, Procedure Type Definitions, 

Specification of procedure variables-in the SHOL must 
express clearly the intent of the programmer,' 

Requirements 

3S-.1, A procedure data type is required, 

3S-.2, Explicit specification of the number and 'types of 
arguments shall be? required for each procedure variable 
definition and must be considered part of the variable's 
value type, [Hence, procedures having different numbers 
or types of arguments cannot be assi^lied to the. same 
procedure variable; see 2D-2, Specifying the argument 
types helps to prevent error and makes programs more 
understandable, ] 

Language Evaluations 

Only PL/I supports procedure variables. Explicit specifi- 
cation of parameters for such variables is not required, 
however, 

3T, Procedure Operations , 

Operations provided for procedure variables must meet the 
requirements of the task dispatching operation (see Section 5,2,8) and 
must be consistent with the rest of the language. 

Require ments 

3T-1. There must be equality and inequality operations 
between elements of procedure type, [These operations 
are required for uniformity,] 
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Language Evaluations 



PL/I provides equality and inequality operations for pro- 
cedure types. 

Language Evaluation Summar y 

The candidate languages are ordered, according to the degree to 
which they meet SHOL procedure data type requirements, as follows: 



PL/L 



* FORTRAN, 
J3B, J73I, 
PASCAL- 

6. 3; 8 Array Types 

Goal 



Provides procedure variables. 
Inadequacies are: 

• parameter specification is not part of the 
variable's value type 

Procedure variables are not provided. 



The SHOL must provide arrays, or composite data types with 
indexible components of homogeneous type. Arrays must be supported 
in a manner which contributes to program under standability and effi- 
ciency, and which meets simulator programming needs as discussed in 
Section 5.3.3. 

Supporting. Concepts 

3U. Array Type Declarations . 

Arrays of the various data types must be specifiable in a 
manner consistent with other type definitions in the language. 

Requirements 

''*3U- 1, Arrays with conriponents of any scalar [including 
proceclure] or composite type shall be definable. [Arra/s 
'of procedures are required to support current methods 
ot foreground tasls dispatching. ] 

»» 

3U-2. Accuracy specifications [see 3A] shallbe required 
for components of appropriate numeric type. 

3U-3. The number of dimensions for each arf^ay variable 
must be specified in programs and shall be determinable 
at translation time. [No need for a variable number of 
dimensions was observed.] 

1 ^ -1 



*3U-4, At least three dimensions are required. [Required 
for 3'-variable linear function interpolation.] 

-'•3U-5, The range of subscript values for each dimension 
must be specified in programs and need only be determi^ 
nable at translation time [i,e,,. specified with constant 
values; however, see 7E-Z for array parameters. No 
need for arrays with varying bounds was observed. ] 

3U-6, The 'range of subscript values nnust be restricted 
to a contiguous sequence of integers, the elements of an 
ordered enumeration type, or a sequence of.single char- 
acters. [These types of .subscripts are sufficient ' for 
simulator needs. ] 

3U-7. The lowest bound of a seauence of integers defining 
the range of subscript values must be language-defined, 
rather than programmer-definable, [This simplifies the 
language, makes subroutine interfaces more efficient, and 
is adequate for the simulator application.] 

Language Evaluations 

All of the candidate languages provide an array data type, 
and all allow at least the required three dimensions. All 
languages permit any of their,, scalar types as array com- 
ponents. (Hence arrays of procedures are supported only 
in PL/I, ) Only PASCAL and PL/I allow arrays of arrays, ^ 
J3B all ows only one-dimensional arrays of records., while 
other languages provide more general support- All 
languages require the same numeric accuracy specifica- 
tions as are required for scalars of the same type. 

The number of dimensions is fixed at compile time for all 
languages. All require that subscript ranges be determin- 
able at compile time except PL/I, which determines ranges 
for automatic and controlled storage at time of allocation. 

Of the candidate languages, only PASCAL allows subscripts 
to be of enumeration type or to be single characters, 
PASCAL also permits Boolean subscripts, which are not . 
desired. Only FORTRAN and J3B have a language-defined ' 
lower bound, 

3V, Array Literals . 

The language must support the initialization of an array - 
with constant values,' This is necessary to create such data structures- 
as the LFI breakpoint and value lists. 
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Requirements . 

3V- 1, A constructor operation [i.e., an operation that 
.constructs an element of a type from its constituent parts] 
is required for array types. 

Language Evaluations 

None of the candidate languages provide an explicit array 
constructor operation. (AH except PASCAL allow initiali- 
zation of arrays with lists of constants. ) 

3V/. ' Array Operations. 

Operations must be provided to allow the use of individual 
array components and of subarrays of arrays of records. Operations on 
entire arrays representing matrices and vectors are alsc required, for 
reasons discussed in Section 5, 3. 3. 

Requirerhents 

-3W-1. A value accessing operation for individual array 
components is required. [This is a fundamental array 
operation. ] 

-3W-2. Assignment to individual array components must be 
permitted. [This is a fundamental array operation.] 

;I-3W-3. Operations for value access and assignment of sub- 
arrays consisting of a complete dimension of an array of 
record components are required. [This allows grouping 
. of related record data, all of which is indexible by the 
same enumeration type, intp a single array, while still 
allowing vector operations on a subarray. Section 5. 3. 4. 2. Z 
illustrates this concept. Note that a uniform language will 
provide for selecting complete dimensions of any array 
type as well. ] 

3W.4. There must be array operations for matrix addition 
and subtraction, multiplication of a matrix by a scalar, 
multiplication of a vector by a scalar, vector cross-product, 
and vector dot product. [Such operations are heavily used 
in simulators, particularly in the Aerodynamics, Visual, 
and Tactics systems. J 

3W-5. Equality and inequality operations on arrays are 
required. 
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Language Evaluations 

All of the languages provide value access and assignment 
for individual array components. Only PL/I'permits selec 
tion of subarrays consisting of a complete dimension af an 
array of,.records. None of the languages provide equality/ 
inequality operations oh arrays. 

Matrix and vector operations are supported only.by PL/l, 
and it supports only, addition and subtraction. 

Language Evaluation Summary . 

The candidate languages are ^rdered, according to the degree to 
which they meet SHOL array requirements, as follows: 

PL/l- Most requirements^are met. 

Deficiencies are: 

• single characters not usable as subscripts 

• • lower bound of subscript range defined by 

programme r 

• no array constructor operation 

• no equality/inequality 

• no matrix multiplication operations 

PASCAL- More subscript types are permitted. Fewer opera- 
tions are provided. 

Deficiencies arc: 

• permits Boolean subscripts 

• lower bound of subscript range defined by 
programmer 

• no array constructor operation 

• no subarray selection 

• no equality/inequality 

• no matrix and vector operations 
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Several desired capabilities are not provided. 
More restrictions are imposed. 

Deficiencies are: 

• only one-dimensional arrays of structures 
permitted 

• no arrays of arrays 

« single characters not usable as subscripts 

• no array constructor operation 

• no subarray selection 

no equality/inequality 

no matrix and vector operations 

J73I- Several desired capabilities are uot provided. 

Array lower bound is programmer-defined. 

Deficiencies are: 

• no arrays of arrays 

/ 

• no single character or enumeration type 
subscripts 

• lower bound of subscript r^rhge defined by 
programmer I 

X . • no array constructor operation 

• no subarray selection 

• no equality/inequality 

• ' ■ no matrix and vector operations 

FORTRAN- As structures are not supported, there are no 
arrays of structures. Desired subscript types 
are not provided as data types. Desired opera^. 
tions are not provided. 
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Deficiencies are: 



• no arrays of arrays 

• no equality /inequality 

• no matrix and vector operations 
6.3.9 Record Types 

Goals ; 

The SHOL nnust provide records, i.e., composite data types v/ith 
labelled components of heterogeneous type [e.g. , PL/I structures]. 
Simulator data organization could be greatly improved by the use of 
records^ as illusti'ated in Section 5.3.4. * 

Supporting Concepts 

3X. Rec o rd Type Declarations . 

Records shall be provided in a uniform and consistent man- 
ner. A variant record type facility is- required for some simulator 
functions. 

• (* 

Requirements 

*3X- 1. Records with components of any scalar [including 
procedure] or composite type are required.' [Restric- 
tions on component types degrade language uniformity.] 

3X-2. Accuracy specifications must be given for each 
component of a real numeric type. [This is for uniformity 
with declaration of simple variables. ] 

*3X-3. It must be possible to define types as alternative 
record strtictures (i.e., variants). [Variants are used 
in simulators, for example, in the radio station and radar 
emitter data files,] 

3X-4. The structure of each variant must be determinable 
at translation time. [This is inherent in the variant record 
concept, ] 

3X-5. Each variant must have a tag field (i.e. , a compo- 
nent that can be used to discriminate among the variants 
during execution). [This 3S inherent in the variant record 
concept. ] 
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3X.6.- The tag field must not be directly a^ssignable 
I Assigrirtent to tag fields changes the type of the vaHant 
For reliability and understandability." such assignments 
must be restricted. ] 5 >.= 



3X-7. The tag field mu^t be stored in the record, and its " 
storage position must be controllable by the programmed 
LSince variants.are used to describe input d4ta records \ 
the programmer must be able to specify the tag field poli j'. ' 
tion in the input record. ISfo use of untagged record varL \ 
ants has been observed, ] , - o 



Language Evaluations 
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V 



All of the candidate languages except FORTRAN provide a 
record data type. All allow components of any scalar' 
type, and all except J3B and J73I allow components of 
array and record types. All requije accuracy^specifica- 
tions as for scalars of the same type. Variant record 
types are supported explicitly by PASCAL, and less 
directly-by J3B and J73I through an overlay feature. 
(PL/I's overlay capability provides some similar functiors 
but less explicitly, ) , , 

iAcr^^J^*^^^'^ variants have a tag fiel^. However, 
Y^bCAL does not require that the tag be stored in the 
record, and if it is, the programmer has only partial 
cc*<itrol over its position. PASCAL does not prohibit 



ass 



ignment to the tag field. 



3Y. RecL V^d Literals . 

The language must support the initialization of a record with 
c^^.rf/'' ^il ^V^^^^ to allow the creation of data tables such as the 
camera/modelboard altitude limit bit map (see. Section 5. 3. 4. 4). 

Reqairernen <-s 

3Y-i. A constructor operation [i. e. , an operation that / 
.constructs an element of a type from its constituent parts] 
IS required for all record types. [Such an operation is 
used to initialize record variables.] 

Language Evaluations 

^None of the candidate languages provide an explicit record 
constructor operation. 
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3Z. Record Operations. 

The SHOL must provide operations to allow the use of 
individual components of records. 

Reouirements 

«^ . 

^*3Z-.l. A value accessing operation for individual record 
components is re^quired, [ This is a basic operation bf the 
type, ] 

''*3Z-2, Assignment to individual record components that 
have alterable values [i.e., all except the tag field] must 
be permitted, [This is a basic operation also.] 

Language Evaluations 

All of the candidate languages provide access and assign- 
ment to individual record components. 

L anguage Evaluation Summary 

The candidate languages are ordered, according' to the degree to 
which they meet SHOL record requirements, as follows: 

PASCAL- Most basic capabilities, including variant record 
type s, are. provided. 

Deficiencies are: 

• tag need not be stored 

• lack of programmer control over tag storage 
position ^r-'"^ 

• tag field assignable 

• no record constructor operation 

J3B, J73I- Variants are not supported as requested. Compo- 
nent types a^e limited, 

Def ic iencie s are : 

^ e no components of array or record type 

• no variants (overlays instead) 
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FORTRAN. 



An overlay capability is provided. 
Deficiencies are: 
• no record variants 
Records are not provided. 



Section Summa r y 

. ^Ranking theJanguages by how well they satisfy the data type 
requirements gives the following ordering: 



PL/I. 
PASCAL- 

J5B- 



acceptable support for all types but Boolean and 
enumeration 

major deficiencies are lack of fixed pcint, bit 
string, and procedure types; and poor character 
s upport 

acceptable support for all types except Boolean, 
enumeration, and procedure 

lacks adequate support for fixed point, enumera- 
tion, Boolean, pointer, and procedure types 

fails to meet most requirements 



J73I- 

FORTRAN 
Expre ssions 
Goal 

Expressions m the SHOL should be provided in a uniform manner. 
Appearance and interpretation of expressions should correspond to 
common usage when this does not conflict with other requirements. The 
FORTRAN background of simulator programmers i3 a consideration in 
the design of this feature. 

Supporting Concepts 

4A, Side Effects, 

Expression evaluation should not alter the environm.ent of 
the expression (i,e,, repeated evaluation of the expression should pro- 
duce identical results). If not, such programs are more difficult to 
understand and, hence, maintain correctly. 
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Requirements 



4A-1. During expression evaluation, assignment must 
not be permitted to any variable. [Note that this pro- 
hibits functions from having assignable (i, e, output) 
param^gters, ] 

4A-2. A function must not be permitted to change vari- 
ables that £.re non-local to the function, [ Note this 
makes functions free of side effects -- two calls with 
the same argument values will always produce the same 
result. This means compiler optimizers can produce 
much more efficient code for programs containing func- 
tion calls. If a, side effect is desired, a programmer 
must use a procedure with input/output arguments.] 

Language Evaluations 

None of the candidate languages prohibit j^unctions from 
having assignable parameters, and hence from altering 
the environment of the expression containing the function 
call. 

4B. Allowed Us age. 

Language uniformity dictates that expressions, variables, 
and constants be usable in the same contexts as one another (wherever 
such usage is sensible). 

Requlrenrients 

» 

4B-1. Expressions of a given type must be permitted 
wherever both constants and variables of that type are 
allowed. [This is a uniformity issue. ] 

Language Evaluations 

FORTRAN fails to meet this requirement. For example, 
variables or constants are required as loop start, incre- 
ment, and end values. 

4C. Constant Valued Expressions . 

, Constant valued expressions support program understanda- 
biUty and ct^Q^diti onal compilation, as discussed in Sections 5. 5. 1. 1 and 
5.5.2. 
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Requirements 



4C- 1. Constant valued expressions (i.e. , expressions 
whose operands all have a constant value or Boolean 
expressions having. *a constant value independent of the 
value of variables contained in the expression, e.g., 
B OR C where C is a constant name having the value 
TRUE) must be permitted wherever constants of the 
types are allowed. Such expressions must be evaluated . 
at.translation time, with target machine accuracy, [The 
use of constant expressions is discussed in Section 
5. 5. 1. 1. ] 

4C-2. Expressions containing function calls with constant 
arguments need not be considered constant valued expres- 
sions. [This constraint is to make compile-time evalua- 
tion of expressions simpler.] 

Language Evaluations 

None of the candidate languages provide full constant 
expression evaluation. J3B probably provides it to a 
greater extent than the others. For example,' only J3B 
supports translation time evaluation of real and pointe.r 
expressions. None of the languages provide ey-aLuation 
of enumeration type or character constant expse ssions. 
Only J3B and J73I provide evalu^xtion of constant bit 
string expressions. 

None of the languages appear^^to require that constant 
expressions be evaluated with target machine accuracy. 

Language Evaluation Summary 

The candidate languages are ordered as follows, according to 
the degree to which they meet SHOL requirements for expressions: 

J3B- Provides more constant expression evaluation 

than others. 

Deficiencies are: 

• functions can assign to parameters 

• incomplete constant expression evaluation 
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Some constant expression evaluation is provided. 



Deficiencies are: 

• functions can assign to parameters 

• incomplete constant expression evaluation 

PL /I, ' 
PASCAL, 

FORTRAN-' Little or no constant expression evaluation. 
Deficiencies are: 
' o . functions can assign to parameters 

• expressions sometimes forbidden where 
constants and variables can be used 

• no translation time evaluation of constant 
expressions 

Constants, Variables, and Declarations 



Goal 

The SHOL must allow declaration of constants and variables in 
a manner supporting program under standability. These features 
should be designed to facilitate translation. time detection of errors 
and to allow generation of efficient object code. These issues are 
discussed in Section 5,5, 1, ' 

Supporting Concepts 

5A, Declaration of Constant Names. 



A constant definition facility allows programmer intent 
to be expressed more explicitly, enhancing maintainability, ^ 

Require men ts ^ 

-'5A-1, The ability to associate identifiers with constant 
values. of numeric. Boolean, character string, bit string, 
array, and record tvpes is required. [See Section 
5. 5. 1.1.] 

5A-2. Type names must be interpreted as abbreviations 
for their values [ i. e, , two record type names having the 
same definition shall be considered equivalent. This 
rule is motivated by language design considerations. It 
leads to a simpler use of a language. ] 

■ m 




Language Evaluations 



Of the candidate languages, only J3B and PASCAL allow 
constant names.. Each allows them for the scalar types 
of the language, but neither allows them for arrays or 
records, 

5B, Declaration of Variables . 

KM-. 1, interest of program under standability and maintaina- 

bility, all variables should be explicitly declared. 

Requirements 

5B-1. The value type of ^each variable must be specified 
explicitly. L Readability is more important than writability 
because of maintainability considerations; see Section 6. 1. ] 

5B-2. The value type of loop control variables must be 
specified as part of the loop control statement. [This also 
is an understandability consideration.] 

•{ 

Language Evaluations 

. All of the candidate languages provide a means to declare 
the types of ^ -^riables, but FORTRAN and PL /l do not 
require expliot declarations for all variables. None of 
the languages allow the type of the loop control variable 
to be specified in the loop control statement. (PASCAL 
and J73r require that it be declared .explicitly in the same 
manner as other variables. ) 

5C. Scope of Declarations . 

Name scoping rules should not be more complex than 
required by the simulator application, in order to allow efficient , 
implementation. 



Requirements 

5C-1. It must be possible to declare variables whose scope 
is at most an entire subroutine body. 

5C-2. The scope of explicit declarations (except fcr loop 
control variables) is not required to be a unit small,;r than 
a subroutine. [This simplication appears to be adequate 
to meet simulator needs, considering the current use of 
FORTRAN.] 
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5C-3. The scope of a loop control variable must be the 
loop control statement and loop body [ see also 6F] . 
[Having this rule permits efficient loop code to be gen- 
erated with less complex optimization processing.] 

Language Evaluations 

All of the candidate languages permit the declaration of ' 
variables whose scope is a subroutine body. PL/I pro- 
vide s • smalle r rfame scope units, a feature which is not 
required. 

ANSI FORTRAN loop control variables are accessible 
only within the loop. This is not true of any of the other 
languages. 

5D. Restrictions on Values . ^ 

The types of values assignable to variables should be those 
necessary to support simulator programming. (For example, as indi- 
cated in Section 5.2.8, procedure variables are necessary for the fore- 
ground task dispatcher.) Excess generality, at the expense of efficiency 
and reliability, is not desired. 

Requirements 

5D-1. Labels and statements must not be assignable to 
variables, computable as values of expres sions , or usable 
as parameters to procedures or functions. [Having the 
forbidden capability encourages complex central flow, 
making programs more difficult to understand*] 

5D-2. Nprocedures and functions are not required to be 
usable sis parameters to procedures or functions, or 
returnable as function values. [ The need for subroutines 
as pararrveters was not observed in our examination of 
simulator pi'Tygrams. ] 

Language Evaluations 



FORTRAN allows the assignment of labels to variables 
in the assigned GOTO statement. J73I allows labels to 
be used as pa^rameters. PL/I provides a general label 
variable type, with use as expression values, parameters, 
function values, etc. , PASCAL and J3B permit none of 
these undesired uses of labels. 

J73I, PASCAL, and PL/I allow procedure parameters, 
which are not required. None of the languages allow pro- 
cedures as function values. 
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5E. Storage Classes . 

As described in Section 5. 1, both static and automatic 
-storage classes are required to support simulator data organization 
n?.H";r^'' These ^cilities should resemble those in other commonly- 
used languages and^shoold facilitate coordination between members of 
the programming group. 

Requirements 

5E-1. The ability to statically allocate variables local 
to compilation units is not required. [Some simulator 
^ ■ customers specify that static storage not be used.]j 

5E-2. It must be possible to statically allocate storage 
for variables which are external to compilation units. 
[ Such data IS required to support the 'datapool' concept 
used in simulator development, in which data is available 
to the various compilation units comprising the system- 
see Section 5. 1. 1. J 

5E_3. It must be possible to have storage for variables 
local to a subroutine initialized (and possibly allocated) 
on each entry to the subroutine. [Values of such variables 
are not preserved from one execution of a scope to the 
next; see Section 5. 1.2.] 

Language Evaluations 

All of the candidate languages except PASCAL, provide 
static storage external to compilation units, (The FOR'T^RAN 
COMMON and PL/I external data concepts are not as simi- 
lar to the 'datapooi;.-facility as is the JOVL^IL COMPOOL 
concept. ) 

All of the languages also provide automatic storage local 
to subroutines. (FORTRAN provides this only in the ser-se 
that entities which are not initialized ^nd which are 
assigned to in the subroutine are undefined on RETURN 
from the subroutine. The storage is statically allocated. ) 



?F. Initial Values. 



Since knowing the initial value of a variable is often 
important in understanding programs, a method of specifying initial 
values snould be provided. r j a 
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c . Requirements 



5F-1. There must be no default initial values for variablei 
[Default initialization can require unneeded object code.] 

5F-2. It ne^d only be possible to initialize any variable 
with a constant value. { Initialization with expressions • 
whose value is only known at run-time is an unneeded 
capability. ] 

Language Evaluations 

None of the candidate languages include default initializa- 
tion of variables (except in a few isolated cases, » 
PL/I AREA data). All of the languages except PASCAL 
provide a means of explicitly initializing variables. 

5G. Operations on Variables. 

It must be possible to assign and use values of variables 
in a uniform, manner. 

Requirements 

=*^5G-1. The assignment operation and an implicit value 
access operation shall be automatically defined for each 
variable. [Note that this includes scalar, array, and 
record variables. This requirement is for language 
uniformity. ] 

Language Evaluations 

All of the languages provide assignment and value access 
operations for scalar types. Only PASCAL and PL/J per- 
mit assignment to arrays. These two languages also per- 
mit assignment to record variables, which is provided 
in only a limited manner in J3B and J73I. (FORTRAN 
does not have records. ) 

Language Evaluation Summary 

The candidate languages are ordered, according to the degree 
to which they meet SHOL requirements for constants, variables, and 
declarations as follows: 

J3B- Almost all major requirements are met. Assign- 

ment to composite types is not fully supported. 
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Deficiencies are: 



J73I. 



PASCAL. 



PL /I. 



• 
• 



• \no constant names for arrays or records 

• lo\^ variable not declared in loop control 
statement 

\ 

• loop friable not local to loop 

• no assignment to composite variables 

Constant names are not provided. -Label paramete 
are allowed. Assignment to composite types is 
not fully supported. 

\ 

no constant naVnes 

• \ ■ V 

loop variable not declared in loop control 
statement 

• loop variable not local to loop 

• label parameters permitted 

• no assignment to composite variables 

Constant names are provided. There is no static 
storage external to compilation units. There is 
no way to initialize variables. 

Deficiencies are: 

• no constant names for arrays or records 

• loop variable not declared in loop control 
statement 

• loop variable not local to loop 

• no external storage 

• no initialization 

Constant names are not supported. Implicit 
declarations are permitted. Undesired capabilities 
are provided. 
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Deficiencies are: 

• no constant names 

• implicit declarations 

• loop variable not declared in loop control 
statement 

• loop variable not local to loop 

• label variables (though some uses of these 
provide a needed capability, in the absence 
of a CASE statement) 

FORTRAN- Few of the desired capabilities are provided. 

Deficiencies are: 

• no constant names 

• implicit declarations 

• assignment of labels to variables permitted 

• no automatic storage allocation 
o no assfgnment to arrays 

• loop variables not declared in loop control 
statement 

6- 6 Control Structures 

Goal 

The SHOL must provide control structures for conditional, 
iterative, and sequential control- These are required by the types of 
processing performed in simulators. Conditional processing is 
particularly prevalent, as discussed in Section 5.4. 1. Control struc- 
tures should be designed to support structured programming and 
enhance readability, and should allow programmers to express concept 
in a notation \which is natural to them. Each control structure should 
provide a single capability. 
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Supporting Concepts 

6A. Basic Control Facility , 

The set of control structures should be simple, under- 
standable, and easy to learn to use effectively. 

7 Requirements 

6A.1. Built-in control mechanisms should be of. minimal 
number and complexity, [.This is for simplicity.] 

6A.2. Each must be distinctively introduced and delimited 
[e.g., IF-ENDIF, CASE-ENDCASE; this tends to make 
the structure of programs more readily perceivable. ] 

6A-3. Nesting of control structures must be allowed. 
[This provides a natural program structure.'] 

Language Evaluations 

All of the candidate languages provide a reasonably simple 
set of control structures. FORTRAN'S control mecha- 
nisms are the least complex, but they do not provide the 
■desired capabilities. FORTRAN is also the only language 
which does not allow nesting of control structures (except 
for loops). 

All of the languages are deficient in the syntax used to 
define the lexical extent of control structures. PASCAL 
requires a terminator for CASE clauses, but it is not 
distinctive. PL/I requires. a non-distinctive terminator 
for loops. All ather control structures are defined by 
compound statements, which are, of course, not distinctive 

6B. Sequential Cont rol. 

The method of indicating successive statements tc be exe- 
cuted should encourage a xniform programming style and should mini- 
mize chances for programmer error. 

Requirements 

6B-1. There must be explicit statement terminators [as 
opposed to statement separators as in PASCAL, or no' 
statement delimiters as in FORTRAN. Statement termina- 
tors have been shown in experiments to be less error- 
prone than separators. ] ' 
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Language Evaluations 



FORTRAN does not have any statement delimiters: In 
PASCAL, the delimiter separates rather than terminates 
statements. The other candidate languages, J3B, J73I, 
and PL/I, all have the required statement terminators. 

6C. Conditional Control, 



There must be facilities for selecting aiijong various' con- 
trol paths based on a condition. Such facilities should support struc- 
tured programming practices and enhance program m-iintainability. 
Complex conditional assignments are needed, for reasons discussed in 
Section 5. 4. 1. 1, 

Requirements 

6C-1. The conditional control structures must permit 
selection of alternative control paths depending on either: 

• the value of a Boolean expression [ IF-THEN, 
IF-THEN-ELSE; this is the basic conditional 
structure] . 

• a computed choice among- labelled alternatives 
L indexed CASE; see Section 5. 4. 1. 2] . 

6C-2. The language must specify the control action for 
all values of the discriminating, condition used to select 
alternatives, [e.g., in an indexed CASE statement, 
there must be a language-defined action corresponding 
to any possible value of the index for which the program- 
mer provides no specific action. Specifying the action 
ensures standardization among implementations.] 

6C-3. The user may supply a single control' path to be 
used when no other path is explicitly selected, [e. g. , 
in an indexed CASE statement, an alternative may be 
specified which is selected when the CASE index does 
not match the label of any labelled alternative; such an 
alternative can contribute to program readability.] 

6C-4. Index values may be of an exactly representable 
scalar type [integers, enumeration elements, character 
strings, or bit strings] and must be constant values. 
[The use of enumeration types as CASE indices is dis- 
cussed in Section 5. 2. 3- 3. J 
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Alternatives may be associated with several index 
values or with a range of index values. [ This capability 
is often convenient and contributes to program readability. 

Language Evaluations \ 

None of the candidate ^ ,nguages provide all of the required 
conditional control facilities. Only J73I and PASCAL have 
a CASE statement. PL/I and J3B have no CASE state- 
ment, and FORTRAN has neither a CASE statement nor 
an ELSE component for IF-THEN statements. The indexec 
CASE statement of PASCAL meets the requirements mT3re 
closely than that of J73I by requiring explicit labelling of 
alternatives with the index value. Only the J73I CASE 
statement allows specification of a control path to be taken 
if no other CASE path is explicitly selected, but such a 
specification is not required. 

The PASCAL CASE statement permits-an index value of 
any exactly repre sentable scalar type, whereas J73I's 
version does not* Specifically, character values are not 
permitted as indices in J73I. Both languages allow an 
alternative to be associated with several index values, but 
only J73I permits index ranges. 

6D. Conditional Expressions . 

It must be possible to clearly and efficiently select alterna 
tive operands within arithmetic expressions, based on a condition. 
Simulator design and documentation involves extensive use of such a / 
feature, as discussed in Section 5.4. 1. 1. 

Requirements 

*6D-1. Conditional expressions, allowing selection of 
alternative expression values based on the value of a 
Boolean expression, are required. [See Section 5.4, 1. 1. 
i 

6D-2. The language must require the specification of the 
expression to be selected for all values of the discrimi- 
nating condition [i.e.. IF-THEN-ELSE] . 

^ ,6D-3. Nested conditional expressions are not desired 
[e.g. , IF (IF. . . THEN. . . ELSE) THEN. . . ELSE. . . ; 
such expressions quickly become unrefidable] . 

Language Evaluations 

None of tho candidate languages allow conditional 

expressions* 




Conditional Compilation . 



A -7 u , discussed in Section 5. 5. 2 and in Sections 4. 6 and 
4. /, It should be possible to speciiy inclusion or exclusion of sections 
of code based on information available at translation time. 

4 

Requirements 

6E-1. When the selected case for any conditional state- 
ment IS determined by a constant expression [ see 4Cl "it 
IS required that only the selected path be compiled. [ This 
IS a means of obtaining conditional compilation capability. ] 

6E-2. When the selected alternative of a conditional 
expression is determinable at translation time it is 
required that only the selected alternative be compiled. 

*6E-3. A method of conditionally compiling declarations is 

required I This supports program portability; see Sec- 
tion 4. 7o ] ' 

Language Evaluations 

. Some form of conditional compilation is provided by three 
of the candidate languages -- J3B, J73I, and PL/I. Only 
J3B supports conditional compilation as specified in the 
requirements, i.e. by normal co/iditional expressions 
V, ith alternatives determinable at compile time. . J73I and 
PL/I provide special compile-time features for this pur- 
pose. However, the J3B facility does not allow conditional 
compilation of declarations, while those of J73I and PL/I 
do. 

6F. Iterrtive Contro l. 

An iteri-cive control (e. g. , loop) facility is necessary to 
support the general iterative processing requirements of simulator pro- 
gramming, and to provide a complete set of structured programming 
mechanisms. ' r o b 

Requirem ents 

*6F-1. There must bo an iterative control structure that 
permits a loop to be terminated before or after each 
execution of the loop body. [ Termination at other points 
may be useful but is not required; the need for this con- 
trol facility is derived from general language design 
considerations. J 
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=^6F-2. There must be a control structure that iterates 
over enumeration types or over subranges of integers ' 
[e. g. , the FORTRAN DO-LOOP; such a structure is 
used quite commonly]. 

6F-3. The value of the contr ol/variable must be accessible 
only as a constant within the control structure. [ Ihis 
makes it easier to optimize loops and avoiq,s errors 
dependent on knowledge of the control variable's value 
when the loop is ex. ted. ] 

6F-4. The control structure must permit zero iterations 
to be specified [^e. g. , DO FROM 1 TO N, where M is less ^ 
than one; not providing this capability is a significant 
FORTRAN failure] . 

I.anguage Evaluations 

All of the candidate languages provide iteration over sub- 
ranges of integers, and all but FORTRAN provide an 
indefinite iteration facility (e. g. , V/HILE or UNTIL). Only 
J73I and PASCAL have an enumeration , data type, so only 
these languages include iteration over enumeration types. 

Only PASCAL and FORTRAN loop control variables are 
read-only v/ithin the loops. In other languages, the con- 
trol variable may be assigned to explicitly. All candidate 
languages except FORTRAN permit zero loop iterations 
to be specified. 

6G. Explicit Contro l Transfer. 

A "go to" statement is necessary, but its use should be 
restricted to encourage programs with an understandable control flow. 
Other types of explicit control transfers are not desired, for reasons 
of language simplicity. 

Requirements 

^^'6G-1. There must be an explicit mechanism for control 
transfer [ i. e. , the "go to"; the need for this feature is 
derived from general language design considerations]. 

• 6G-2. The "go to" must not permit transfer into loops or 
out of procedures. [ Permitting such transfe/s is error- 
prone. ] 

6G-3. The "go to" must permit transfer from one case 
constituent to anothei . [ This ccn make it easier to get 
efficient object code. ] 




6G-4, Control transfer mechanisms in the form of switches, 
des^gnational expressions, label variables, label parameters, 
or alter statements are not desired, [These are considered 
to be error-prone in their use and contribute to complex 
program control flows that are hard to understand, ] 

Language Evaluations 

All of the candidate languages include a "go to" statement. 
None i-estrict its use to the extent required. In particular. 
J73I, PA'SCAL. and PL/I allow t r ansfe r s ' out of procedures 
and FORTRAN and J3B allow transfers into loops. 

Both languages with CASE control structures (J73I and 
PASCAL) allow transfers fi:om one case constituent to another. 

Only PASCAL and J73I limit explicit control transfer mech- 
anisms to the "go to, " FORTRAN and J3B allow switch or 
indexed "go to" constructs, and PL/I has label arrays. 
These features are provided to .supply the capability which 
^ is supplied by the CASE statement in PASCAL and J73I, 
' so they are not redundant, 

<i> 

Language Evaluation Summary 

r 

The candidate languag.-s are ordered, according to the degree to 
which they meet SHOL control structure requirements, as follows: 



J73L 



A]l major functions except conditional expressions 
are provided. 

Deficiencies are: 



PASCAL- 



non-distinctive syntax 

explicit labellip^>of CASE alternatives not 
r equi red ^ 

CASE indices of character type not allowed 
no conditional expressions 

conditional compilation not implemented in 
required manner 

assignment to loop control variable permitted 
transfer out of procedures permitted 

All major functions except conditional expressions 

are provided. Conditional compilation is -not supported, 

Defiriencies are: 



• .non-distinctive syntax 

• statement separators rather th. :i terminators 
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• no- way to specify 'ELSE* control path in CASE 

• CASE alternatives cannot be associated with 
index ranges 

0 no conditional expressions 

o no conditional compilation 

• transfer out of procedures permitted 

J3B- CASE statements and conditional expressions are 

not provided. (Switches provide a capability similar 
to the CASE statement.) Conditional compilation is 
supported ^by the compile-time determination of 
alternatives in regular conditional control structxires. 

Deficiencies are: 

o non-distinctive syntax 

• no CASE statements (switches instead) 
0 no conditional expressions 

• no conditional compilation of declarations 

a iteration over enumer^^tion types not available 
(because there are no enumeration types) 

• assignment to loop control variable permitted 

• transfer into loops permitted 

PL/I- CASE statements and conditional expressions are 

not provided. (Label arrays provide a capability 
similar to the CASE statement.) Conditional 
compilation is not provided in the required way. 

Deficiencies are: 

• non-distinctive syntax 

• no CASE statements (label arrays instead) 

• no conditional expressions 

• conditional compilation not implemented in 
the required manner 

• iteration over enumeration types not available 
(because there are no enumeration types) 

*> • transfer out of procedures permitted 

FORTRAN- CASE statements, conditional expressions, and IF- 
THEN-ELSE sti*uctures are not provided and the 
object of IF-THEN may only be a single statement. 
Conditional compilation is not supported. 
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Deficiencies are: 



• non-di stinctive s yntax 

• no statement delimiters 

« no CASE statements (indexed ^go to's^ instead) 

» no ELSE component in IF-THEN 

• no conditional expressions 

• no conditional compilation 

• no indefinite iteration facility 

• iteration over enumeration types not available 
(because there are no enumeration types) 

• specification of zero loop iteVrations not:^'\^ 
permitted 

• transfer into loops permitted 
^« ^ Functions and Proc edures 

Goal 

The SHOL must allow the specification and use of subprograms 
(i.e ...functions and subroutines). This feature is necessary to support 
modular programming and is required by simulator system organiza- 
tion as discussed m Section 5. 2. 9. It should be provided in a manner 
which contributes to program under standability and which facilitates 
the production of efficient object code. 

Supporting Concepts 

Function and Procedure Definition s. 

if 

The subprogram capabilities provided should support cur- 
rent practices of simulator organization. 

Requirements 

-7A-1.,A means of defining and invoking functions (which 
return values to expressions) and procedures (which can 
be called as statements) shall be provided. 
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7A-2, Neither recursion nor the nesting of function and 
procedure definitions is required. [Such usage was nol; 
observed and not considered necessary,] 

7A-3, Reentrant procedures are required, [These are 
used by certain, system subroutines in simulators, e, g, , 
conversion routines,] ^ 

s 

Language Evaluations 



All of the candidate languages provide function and pro- 
cedure capabilities; All except FORTRAN provide more 
capability than is required. In particular J73I, PASCAL, 
and PL/I allow nesting of definitions; and J3B, J73I, 
PASCAL, and PL/I allow recursion, (In 'J3B, only pro- 
cedures designated as reentrant maybe called recursively,) 
Only J3B, J73I and PL/I have reentrant procedures. 



7B, Function Declarations, 

Functions nee'd only return those value types required in 
simulator programming, and should not add unneeded implementation 
complexity to the language. 



Requirements 

7B-1, If a function result is a composite value or a bit 
string, then restricting its size to a constant value is 
sufficient to meet SHOL requirements, [This significantly 
simplifies a language,] 

•'•7B-2, Function results of all scalar types except charac- 
ter string and procedure are required, [Functions 
returning character string or procedures present some 
implementation problems. The need for such functions 
is n'ot significant in simulator programming, ] 

7B-3, Function results of label or procedure types are 
not desired, [Languages permitting such types are sig- 
nificantly more complex in their semantics and use of 
these functions can easily lead to programs that are hard 
to understand, ] 

Language Evaluations 

All of the candidate languages-except J73I allow function 
results of all scalar types in the language (except charac- 
ter string and procedure)i (Of course, not all of the 
languages have all of the scalar* types required by the 
SHOL, ) 
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PL/I allows function results of label type, which are not 
desired. . Many of the languages provifde result types not 
specifically required (e.g., character string). 

7C. Formal Parameter Classes. 



Read-only and read/write parameters should be distinguish, 
abie from one another, in support of program readability and reliability. 
The language should permit implementations to provide efficient calling 
sequences for common cases. 

Require men t s 

7C-1. Two classes of formal procedure parameters are 
required : 

a) input parameters, which act as constants that are 
initialized to the value of the corresponding actual 
parameters at the time of the call [i.e., assignment 
toNsuch parameters is not permitted; this helps to 
reduce errors and can contribute to object code 
efficiency. ] 

b) input-output parameters, which enable access and 
assignment to the corresponding actual parameters. 

7C-2. For input-output parameters, the corresponding 
actual parameter must be determined at time of call and 
must be a variable or an assignable component of a 
composite type. [This is to reduce errors and ensure 
efficient implementations. ] ^ 

7C-3. The cjass of a parameter must be distinguishable 
in the form of the call statement. [This is to enhance 
understandability. ] 

7C-4. The language must permit input parameters to be 
safely passed either by value or reference, depending on 
which method is determined to be most efficient by an 
implementation. [This means that even when procedures 
are separately compiled, it must 'be possible to determine 
whether the value of an actual input argument can be modi- 
fied by assignment directly to the variable serving as the 
input argument. ] 

L anguage Evaluati ons 

Only i3B, J73I, and PASCAL allow specification of formal 
parameters as read-only or read/write (i. e. , input or 
input-output).^ In PASCAL, the distinction is not apparent 
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in the call statement, however. Only J3B permits the 
implementation to select between call by value and refer- 
ence for input parameters, but.it does not do this safely. 

"^D. Pa rameter Specifications. 

Relationships between actual and formal parameters should 
be expressed readably in the language. Parameter matching rules 
should agree with the typing philosophy of the language. 

Requirem ents' 

7D~1. Procedure parameters must be positional { i. e. , 
correspondence between formal and actual parameters 'is 
determined by position in the parameter list. Optional and 
keyword parameters are not required]. 

7D-2. The syntax for declaring types and attributes of 
formal parameters must be essentially the same as that 
for variable and constant declarations [to promote 
uniformity]. 

*7D-3. Parameters nay be of any type, but procedure 
parameters are not required. [See 5D-2. ] 

ID. 4. The ac-Mracy of each formal parameter of appropri- 
ate numeric t ^ must be specified. [This is uniform with 
the requiremi-'nt for accaracy specification in other 
contexts. ] 

1°"^'r V"^ ^^'^"^^ °^ ^^^^ actual parameter must match 

that of the corresponding formal parameter. [This implies 
that the language must be de.«5igned so that this check can 
be performed at compile. time, since type interface errors 
are difficult to discover during program development and 
maintenance. J 

Language Evaluati ons 

All of the languages have positional rather than key^vord 
■ parameters, and none allow optional parameters. All 
require a declaration format for parameters wh^ch is 
similar to that required for variable and constant declara- 
tions. Similar accuracy specifications are also required. 

In general, the languages allow parameters to be of any 
type available in the language. All languages except J3B- 
allow procedure parameters, v/hich are not required. " 
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' All of the languages require some degree of correspondence 
between the types of formal and actual parameters, PL/I, 
which allows numerous implicit conversions between 
parameter types, diverges most widely from the require- 
ments in this area, J73I also allows such implicit conver- 
sions. FORTRAN and J3B essentially require exact , 
matching between formal and actual parameters, (The 
PASCAL language specification does not define parameter 
matching requirements, ) 

7E, Formal Array Parameters 

It should be possible to pass array parameters efficiently 
as long as the flexibility necessary for simulator programming is 
supported. 

Requirements 

7E-1, The number of dimensions for formal array param- 
eters must be specified in programs -and fixed at transla- 
tion time, [See 3U-3. ] 

'^'VE-Z, The language must allow the determination of the 
subscript range for forma), array parameters to be delayed 
until execution time, and to varyirom call to call, [This 
is required for Linear Function Interpolation, as discussed 
in Section 5, 2, 9- 3, 2, ] 

7E-3, Subscript ranges must be accessible within function 
and procedure bodies without being passed as an explicit 
argument, [To avoid errors.] 

Lang u age Evaluations 

All of the candidate languages require that the number of 
dimensions for formal array parameters be specified and 
fixed at translation lime. Only FORTRAN and PL/I permit 
the determination of the subscript range to be delayed until 
execution time. Only PL/I makes the subscript range 
accessible within the procedure (through the HBGUND and 
LBOUND functions) without requiring that it be passed as 
an explicit parameter. 

Language Evaluation Summary 

The candidat^languages are ordered, according to the degree 
to which they meet SHOL function and procedure requirements^ as 
follows: % 
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Parameter access restrictions cannot be specified. 
Array parameter subscript range can vary. Exact 
parameter matching is required (though many types 
required by the SHOL are not supported). Excess 
capabilities are minimal. Reentrancy is not 
provided. • 

Deficiencies are: 

> 

o no parameter access restrictions 

/ 

• subscripj^ range of array parameters must be 
passed a"s'"a parameter 

• no reentrant procedures ■ 



J3E. 



All major requirements except array parameters 
of execution-time determinable subscript range 
are satisfied. Exact parameter matching is 
required. Excess capabilities are minimal. 

Deficiencies are: 

© array parameter subscript range is fixed at 

compile time 

• does not permit safe selection between value 
and reference parameter passing by the 
implementation • 



J73L 



PASCAL- 



Array parameter subscript range is not determi- 
nable at execution time. Implicit conversion 
occurs in parameter passing. 

Deficiencies are: 

• implementation cannot select between call by 
value and call by reference for input parameters. 

• implicit conversion in parameter passing 

• array parameter subscript range fixed at com- 
pile time 

nable at execution time.^ Parameter, matching 
rules are undefined. ' Parameter access restric- 
tions are not determinable in the call statement 
Keentrancy is not provided. 
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Deficiencies are: 



• parameter access restriction not apparent in 
call 

• ^ implementation cannot select between call by 

value and call by reference for input parameters 

© parameter matching rules undefined 

• array parameter subscript range fixed at com- 
pile time 

• no reentrant procedures 

PL/I- Array parameter subscript ranges can vary. 

Implicit conversions occur in parameter passing. 
Parameter access restrictions cannot be specified. 
Excess capabilities are provided. 

Deficiencies are: 

• labels permitted as function re^^ults 
e no parameter access restrictions 

• implicit conversion in parameter passing 
8 Input-Output Facilities 

Goal 

Simulator programming requires file-level I/C as well as low- 
level, primitive I/O. Section 5.3.2 discusses simulator file usage; 
Sections 5. 5. 6 and 5. 7 deal with low-level I/O requirements. File I/O 
should be provided through the SHOL, but low — level I/O is probably 
best provided by the development of a'ppropriate assembly language 
library subroutines. 

Supporting Co n cepts 

8A. File Level Input-Output Oper ations. 

Operations for manipulating logical files must be provided 
in a manner supporting program portability. 

Requirements 

-!'8A-1. Standard library subroutines for logical £file I/O 
must be provided. . These must include operatioris for 



creating, deleting, openine, closing, reading, v/riting, and 
positioning logical f:ies. [The need for all these opera. 
^ tions was observed. ] 

8A-2. Library sabrouthies for formatted I/O must be pro- 
vided. [Formatted I/O i': useful in offline work; see Sec- 
tion 5,3.2.] 

8A-3, Binary record files of types sequential, indexed, 
and direct are required, [Use of all these file types was 
observed, J 

8A-4, Blocks of fixed or variable length are required, 

[ The need for variable length blocks is consistent with the 

need for variant records,] 

8A^5, Files must be accessible in read-only, write-only, 
or update mode, [Use of these modes was observed, ] 

^A-6, Shared file operations are not desired, [Unneeded 
" complexity. ] 

Language Evaluations 

J3B and J73I provide no file I/O capability. The PASCAL 
file I/O feature is a primitive one v/hich does not really 
meet any of the requirements. 

FORTRAN and PL/I both provide file I/O facilities, 
FORTRAN supports only sequential files, not indexed 
or direct. Both languages support formatted I/O. 

FORTRAN supports only fixed length blocks and does not 
allow specification of file access restrictions (i.e., read- 
only, write-only, update), PL/I supports shared file 
Operations, which are not desired. 

Operating System Independence . 

In support of program portability, the SHOL must not 
presence of an operating system. 

Require ments 

8B-1. The form and meaning of built-in and standard 
library definitions shall not be restricted to any given 
operating system^s capabilities, if one is present, [Note 
that functions and operators of the language ca'n be imple.. 
mented as operating system calls where the operating 
system is compatible with the function or operator 
definition. ] 



Language Evaluations 



None of the candidate languages I/O features require -the' 
presence of a particular opera,ting system. 

Language Evaluation Summary 

The candidate languages are orderv^d, according to the degree 
to which they meet SHOL I/O requirements, as follows: 

All required functions are provided. 

Deficiencies are: 

• support of shared file operations 
Some required functions are {provided. 
Deficiencies are: 

• no indexed or direct files 

• no variable length blocks 

• no file access restrictions 

Little file I/O support is provided (though the 
primitives could be used to build the desired 
functions). 

Deficiencies are: • 

• file I/O support is too primitive 
No I/O is provided. 

6. 9 Parallel Processing 
Goal 

' ■ ■ .-J 

» 

The SHOL must support the use of multiple processors, as this i 
necessary to achieve the execution speed required for simulation. Simu 
lator executives, which handle inter^CPU communication and data 
sharing, should be programmable in the SHOL. However, since this is 
an evolving area of language design with little consensus on how SHOL 
requirements are best supported, satisfying both these specific require- 
ments and the general requirements (Section 7. 1) may be beyond the 
current state-of-the-art. 



PL/I- 



FORTRAN. 



PASCAL- 



J3B, J73I- 



I 

Supporting Concepts 

9A, Inter-CPU Communicati on. 

The language must support control flow between CPUs 
necessary for simulators, as described in Section 5. 4. 2. 

Require ments ' ^ - 

-9A-1. It must be possible to initiate execution of a speci- 
fied procedure on another CPU, to halt another CPU and 
to release another CPU from a wait state [ see Section 
5, 4. 2J . 

Language Evaluations 

PL/I is the only one of the candidate languages to provide 
any parallel processing primitives. They are, however 
perhaps too high-level to meet the specific requirements. 

9B. Mutual Exclusion and Synchronization. 

Processes executing on different CPUs must be able to 
access system data in a non-conflicting manner. There must be support 
lor synchronization of processes executing on different CPUs as dis- 
cussed in Section 5. 4. 2. 

Requirements 

-9B-1. There must be mechanisms for mutual exclusion 
and synchronization of processes executing in parallel 
[ These are the HOL forms of primitives currently defin-d 
in assembly language. ] 

-9B-2. During specified portions of its execution, a 
parallel process nrist be able to seize and release certain 
progr,:w-n declared objects. [This is to ensure that variabl.^ 
are read and updated in a consistent state.] 

*9B-3. Tiio mechanisms provided must be sufficiently 
general to permit user construction of more specialized 
mechanisms that exploit knowledge of the overall beh ior 
of the system being programmed [ e. g. . that pre-emptir. 
an executing process may not be required because infer." 
rupts are treated on a polled basis; this requirement is 
to ensure that the necessary level of executive efficiency 
can be obtained]. 
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Language Evaluations ' " ^ 

Again, only PL/I provides any support in this area, through 
its EVENT variables and associated SIGNAL and WAIT 
statements. 

9C. Real-Time Clock . 

Access to a real-time clock is necessary to support the 
cyclic operation of simulator programs. Access should be provided in 
a machine-independent manner. 

. .Requirements 

-••9C- 1. There must be means of accessing a real-time clock. 
[Real-time clocks are used for various purposes, as dis- 
cussed in Section 5.4.2.] 

9C-2. There must be translation-time constants lo convert 
between the implementation units and the program units 
for the clock [ supports program portability] . 

Language Evaluations 

• The PL/I TIME function returns the time in machine- 
independent units (hours, minutes, seconds, and milli- 
seconds). However, this function presumably accesses 
a time-of-day clv ck, rather than a real-time clock (which 
can be set to a specific time and will interrupt on comple- 
tion) as desired in simulator programming. The PL/I 
DELAY statement, allowing a task to be delayed for a 
specified time interval, provides more nearly the desired 
capability. 

Language Evaluation Summary 



T hv candidate languages are ordered, a c c o rd i n g t o tin.' 1 e : ; r e e to 
■ which they fneet SHOL parallel processing requirements, as fi^Ilcws: 

PL/I- All rec] ui re men ts are supported to some extent. 

I3e f i c ieii c ie s are: 

• support may be too high-level 

9 r«.*a 1 - t i me fe a t u re s ma y not pro vi d e the desired 
t t rol 
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J3B, J73I, 
PASCAL, 

t ORTRAN- No parallel processing support is provideu. 
Deficiencies are: 

• no support for inter^CPU communication 

• no support for mutual exclusion and 
syrnchronization 

• nc real-time clock access 

^- 1° Specification of Object Representation and Optimization 
Goal 

The SHOL must provide programmer control of and access to 
the object code representation of programs. Control of object repre- 
sentation allows the programmer io make trade-offs between time and 
space efficiency, as discussed in Section 4.4. Access to object repre- 
sentations facilitates the production o: portable programs, as described 
in Section 4, 7. 

Supporting Concepts 

lOA. Packing of Composite Types . 

Control over packing of composite types must be provided 
m order to allow the programmer to ma^e time-space trade-offs This ' 
shoulri be machine-independent when possible, to allow program porta- 
bility. The logical grouping of record data components should be inde 
pendent of the record's physical structuring. 

Requiremen ts 

-lOA-1. The language must permit, but no,t require, 
programmer specification of degree of packing [e.g. , 
tight, dense, medium, unpacked] in a machine- 
independent manner for composite data types [arrays 
and records] . 

^^lOA-2. For^Tecord types only, the language must per. 
mit, but not require, machine-dependent pa-king speci- 
fications [ i. e. , by actual bit positions. This is neces- 
sary to allow description of simulator I/O data.] 

lOA-3. It must be possible to specify the order in 
which components of record types are sequenced in 
storage, independent of the order in which the connponents 
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are^listed in the record declaration. [This can con- 
tribute to understandability by permitting logically 
related Components to appear close together in program 
text even though they might be physically separated, ] 

lOA-4, For two objects to.be of the same value type, 
they must have the same physical representation, [Thus 
packing changes the type of a variable for purposes of 
parameter passing or assignment, i, e. , a formal and 
actual parameter must have identical physical repre- 
sentation specification.] 

lOA-5, The default size of numeric data must be 
dependent on the ra:ige specification, if given, and other- 
wise must be implementation-dependent, [This is a 
consequence of making range specifications optional.] 

*>' 

Language Evaluations 

Of the candidate languages, only JiB, J73I, and PL/I 
provide programmer control over parking of composite 
types. Of these, only J73I and PL/I permit specification 
of array packing. Only J3B and J73I provide machine- 
dependent packing of record types. Neither permits 
the specified packing to be separated from the logical 
structure of :he record, though serial or parallel organi- 
zation may be specified. 

Both J73I and J3B require that composites have the same 
packing to be of the same type, PL/I does not meet this 
requirement. 

lOB. Translation Time Constants and Functions . 

Environmental enquiries, providing programmer access 
characteristics of the object program representation, are needed 
allow t"\e development of more portable programs. ^ 

Requremen ts 

lOB-1. ri : language must p'^trmit the specii-.CiUon of 
object maciiine v onfiguration constants indicating, for r 
example, n^iachine modjl, peripheral equipment, memory 
size, word len^.h, etc. [These c^re used to state what 
environment a program is intended to execute in- ] 

lOB-2. The language must supply translation : rue con- 
stants and functions which access implementation informa- 
tion incluc. .ng: 



maximum and minimum integer values 
negative number representation 
fixed point accuracy ' 

floating point precision, radix, and exponent range 
maximum string length 
default character set 
bits per character 
Language Evaluations 

Only J73I and PASCAL provide an y envi ron mental enquiry 
capabilities. Specifically, J73I provides 

• word length 

o memory size 

• bits/word 

• bits/character 



9 bits /pointe r ^ 
PASCA J provides o-^ly the maximum ' eger value, 
IOC. Code Insertions. 

Assembly language insertions are necessar y-tcTimplement 
machine-dependent simulator functions (see Section 5.7) and sometimes 
to achieve the necessary efficiency in certain areas. Such insertions 
should be easily isolated from other code, in order to support proeram 
portability. ^ 

Requirements 

-lOC-1. The language must permit the definition of sub- 
routines in assembly language. [See Section 5.7.] 

lOC-2. ^'t'lri .i-;sfnTbly language insertions are not 
desired, j t ^tnction of assembly language to sub- 
routines allows control over the data accessed within 
the assembly code. J 

lOC-3. The language must minimize the need for code 
insertions [by providing sufficient flexibility and power 
in the HOL] . 



Language Evaluations 



None of the candidate languages provide any assembly 
language insertion facility. 

lOD. Inline Procedures. 

In order to support programmer control over space-time 
efficiency trade-offs , the language must allow subroutines to be either 
expanded inline or called as actual subroutines. Section 5.2.9.2 dis- 
cusses the value of such a feature in simulator programming. 

Requirements 

•!*10D-1. The language must. permit subroutines to be 
defined as ^inline* -- that is, the code is to be inserted 
directly into the program at the point of call, rather 
than called through a subroutine call mechanism. [See 
Section 5.2.9.2.] 

10D-.2. The 4nline^ specification must be part of the 
definition or in a separate declaration rather than part 
of the call, [identical calls for the two kinds of sub- 
routines facilitate tuning for the desired time-space 
trade-offs, as only the definition need be changed. J 

10D-.3. Inline substitution must not change the logical 
effect of a program, but where substitution of actual 
for formal parameters permits conditional compilation 
of inline code, this must be done, [e.g., if F(X) is 
defined as IF X > 3 THEN. . . ENDIF. then F(2) w^ould 
result in no code being compiled. This encourage s .the 
, modularization of programs and suppor reusability; 
see Section 6. 6. ] 

Language Evaluations 

Only J3B provides inline subroutines. The 'inline^ speci- 
fication is not iTi the definition or the call, but in a 
separate inline declaration. ' This serves essentially 
the same purpose as specification in the subroutine defini- 
tion. J3B performs conditional compilation of inline 
code when parameter substitu^rcn permits, as required. 

/ 

i 0 E . Op tinii z -.• t i on . • . - 

Thefl^.g^age shall permit efficient code optimizations. 



Requirements 

lOE-l. Range specifications, when given; shall be 
assumed to be satisfied when performing code optimiza. 
tion, [This will encourage the use of range declarations. 

Language Evaluation s 

The only candidate language with any range specification 
capability is PASCAL, with integer subranges. 'The 
effect of such specification on optimization is not defined 
by the language. 

Language Evaluation Summa ry 

The candidate languages are ordered, according to the degree to 
which they meet SHOL requirements for specification of object repre. 
sentation and optimization, as follows: 

J3B. Most major requirements, including that for inline 

procedures, are met. Array packing cannot be 
specified. 

Deficiencies are: 

• physical structure of records not specifiable 
independently of logical structure 

• array packing not specifiable 

• no environmental enquiries 

• no assembly language subroutines 

J73I- Major requirements, except that for inline pro- 

I cedures, are met. 

Deficiencies are: 

• physical structure of records not specifiable 
independently of logical structure 

all desired environmental enquiries not 
provided 

• no assembly language subroutines 

• no inline procedures 
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PL/I~ No machine-dependent packing or inline procedures 

are provided. 

Deficiencies are: 



o no 'mauchine-dependent packing 

V uiiysical s true lure of records not specifiable 

independently of lofvical structure 

• records with different packing are of same 

type (i.e. , implicit packing conversions are 
perfur med) 

^ no environmental enquiries 

o no assembly language subroutines 

no inline procedures 



PASCAL- Packing specifications are not provided. Most other 
functions are also liot provided. 

Deficiencies are: 

• no par] specifications 

© little t;7v^. , .'-.vf, rnental enquiry capability 

• ' no enihVv .i inguage subroutines 
© nc in':ne edures 

FORTRAN- Few of the rer.''.ir-"r inunctions are provid d. 
Def iciencie ^ v ■ 
© no packing specifications 
» no environmental enquiries 

• no assembly language suhr :)'jtines 
« no inline procedures 

Libraries and Separate Compilation 
Goal 

A<: discussed in Section 4. 1, the SHOLr rriust support development 
-^uU;- jr systems by large groups of progra: jmers. 
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Supporting Concepts 



llA, Library Entries. 

The language must :.irovlde for the use of common (or 
global) data definitions, subroutine/ js, etc. by the various individuals 
developing the system. 

Requirements 

''•llA-l. The lanr':oge must support the use of an external 
library. [Such libraries are customarily in use today.] 

11A-.2. Library -intries mus: itr/.lude input^output 
packages, con-mo^; pools of shared declarations, appli- 
cation oriented .•rvf'wai^e pa:.kageSj other separately 
compiled seg,.i<^ntfe, and m., nine configuration 
specification r.. 

I * anpuage Evalv. ::i t i o i - ; , \ 

The J3B and J73I CClVPOOLs meet this requirement 
most closely. Other iKnc^iiages provide some similar 
capabilities through rht-ir -supoort of separate compilation 
(see IIB). FORTKAIn's COMMON facility provides 
sharing of conin-on <^ata definitions. 

1 1 B . Separate ly C;.> i n / nled Segm e n t s . 

The languag^^' must allow separate compilation of programs, 
and must support their in./; gration. 

Require men ts 

-llB-i. The language must support the integration of 

separ?ile.). :/ compiled program segments into an operational 
• prograro. 

-I lB-2. Thi^ language must allow definitions made in one 
segment to . c- used in another. [This supports the data- 
pool concept; see Section 5, 1. 1.] 

I^ang ua ge Evaiaalio n s 

J3B and J73I support the use of separately compiled seg- 
ments via the COMPOOL facility. The other candidate' 
languages provide explicit 'external' declarations to access 
external names (though in PASCAL this is an extension to 
the standard language). 
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HC. Restrictions on Separate Compilation. 



In support of program integration, the language must pro- 
hibit inconsistencies among the segments being integrated. 

Require ments 



"''llC-l. Separate compilation must not change the meaning 
of a program. [This simplifies the language, making 
separate compilation merely a development aid. ] 

llC-2. Translators must be responsible for the integrity 
of object code in affected segments when any segment is 
modified. 



llC-3. Translators must ensure that shared definitions 
have compatible representations in all segments. [This 
is of considerable value in program development and 
maintenance. ] 

Language Evaluations 



J3B's and J73I's checking of procedure parameters in the 
COMPOOL and PASCAL'S external reference checking 
provide more enforcement of compatibility than do the 
FORTRAN and PL/I facilities. It does not appear that 
separate compilation affects meaning of programs in any 
of the languages. It also does not appear that any of the 
languages require that translators guarantee integrity of 
object code in affected ^segments when a segment is 
modified. 

Language Evaluation Summar y 

( The candidate languages are ordered, according to the degree to 

which they meet SHOL library and separate compilation requirements, .as 

/"^ll^ A 



follov/s: 



J3B, j73I- COMPOOL facility provides most of the required 
f unction<£ . 



Deficiencies are: 



« integrity of affected segments not guaranteed 

when a segment is modified 

PASCAL- There is no COMPOOL-like facility. Parameters 
are checked in external procedui-e declarations. 
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Deficiencies are: 



• inadequate facility for sharing common 
definitions 

• integrity of affected segments not guaranteed 
when a segment is modified 

PL/I, 

FORTRAN^ There is no COMPOOL-like facility. Parameters 

are not specified in external procedure declarations. 

Deficiencies are: 

• inadequate facility for sharing common 
definitions 

e integrity of affected segments not guaranteed 

when a segment is modified 

• external procedure parameters not checked 
12 Language Evaluation Summary 

A summary of the language evaluations is co^ntained in Table 1. 
For each area of the requirements, each language is given an overall 
rating based on how well it satisfies the requirements. Languages that 
satisfy the essential (i.e., the starred) requirements are rated higher 
even if they do not satisfy the non-essential requirements, since the 
purpose of this evaluation is to decide whicn unmodified language best 
satisfies simulator requirements. The Table indicates that PL/I and 
J3B are most suitable, although no language is perfectly suited (a p:.-rfect 
language would have a score of 90). jiOf the two languages, PL/I is the 
more widely known, although neitH^r PL/I nor J3B is significantly 
supported by manufacturers of comjiuters used in training simulators. 
Also, neither language is approved by DoD for use in new..embedded com- 
puter application efforts. Only FORTRAN and JOVIAL J73I are approved 
languages. From an Air Force viewpoint, JOVIAL J73I would there, 
fore be the best choice if it were more widely available. On technical 
grounds alone, however, PL/I or J3B are somewhat superior to JT3I. 
The only language that is clearly inferior is FORTRAN^ 

Since all of the languages have some important deficiencies, in 
the next Section we will discuss what language is most suitable for 
modification and how well the modified language would meet simulator 
requirements. 
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TABLE 1 
EVALUATION SUMMARY 





PL/I 


i ORTRAN 


PASCAL 


J3B 


J73I 


General Syntax 










'r- -nr "T" 


Numeric Type 


!|; ^ ;Jj T-J: ;J: 




0< ,1. 

'I- »r 


•T> -C T -»» -|» 


.p -nr- 


Enumeration Type 


• 


• 


U« 

-r- »T* I- -T* 




•p 


Boolean Type 




jjc ^ >r* •{^ »j» 


'c- ^ -n. 'T" ^' 


• 


• 


Character Type 


:J; ^4 r|: 


- 






«!. kt^ 


Bit String 




• 


• 




U. ^t. U« 
T- ■'i- 'i- T" T 


W 111 X 


J,': iji j}' 


• 


•n f -n f -««■ 


•4e O. ■.*. 
•T> -n '»» 




Procedure 


^. O, -J. 

»f »l* 1* 












vJ^ kI^ ,1, 


-.1. «•> 


>i. ^, 
-1- 5i» -i- 


«!, 
•V -1- 


^ 3^ ^ ^ 


Record 


^b ..L. 
-I" 'i* f 


• 


•c- 'r- 


J- U, ..t. 

•V -r -I- 


«i' 

•'r -n 


Expressions 








-b 

1' T" -I- 


kI« «t, «J< 
T- -I- T" 


Declarations 






-I" 




«JU J- 


Control Structures 


O. 

'i* T" -1- 




u. .J. gL. 
'1 — n 


^' "T" 'j' 




Procedures 


xt. .I, .JL. 

-I* 'r- T- 


-A, «t. U. U< 
T* -I- -T* 'f -I' 


u. ..t. 






I/O 


^: 


J, OL. ,1. 
-P -I- -I* 








Parallel Processing 




• 


• 






Object Program Cntrl 


-1* -I' 'I' 


.1. 




,t. ,t. ,1, 


^, 

T- 1^ »|* 


Library Facilities 


.1. .1. 


'»* 'l' 




J. o. .1. 


■J, «L, ,t. «JL, 

I" 'I- -!«■ -r I" 




54 


29 


47 


51 


46 



- Good, = Medium, 



= Poor, . = Nonexistent 
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Section 7 



LANGUAGE MODIFICATION GOALS 



Since none of the languages are entirely suitable for simulator 
programming, we will consider what language is best suited for modifica- 
tion and what modifications should be made. In selecting a language for 
modification, in determining the modifications to be made, and in actually 
modifying the language, several goals must be given consideration. These 
goals are discussed in the following subsections. Specific modifications 
to each of the candidate languages are discussed in Section 8. 



7. 1 Minimal Cost 



It is, of course, desirable to minimize the costs associated with 
language modification, i. e. . /the design, . implementation, and retraining 
costs. This consideration dictates that possible modifications be evaluated 
with respect to their value and necessity for simulator programming vs. 
their cost before they are. recommended. Each modification selected adds 
to the cost of producing the SHOL. In addition to the individual cost of 
implementing each modification, as the number of modifications increases 
the complexity ol the overall modification task multiplies. This is because 
of the effect of each addition or deletion on the remainder of the language. 
There are many interrelationships between the features of a language 
which must be carefully considered when deleting a feature and which 
must be defined when adding features. With a large number of modifica- 
tions, interactions can become so complex that it might no longer be cost 
effective to modify an existing language as opposed to simply developing 



a new one. 



Another area of cost, cons ideration in the availability/ of existing 
support for the language selected as a basis for modi.icatioA. If trans- 
lators for the chosen language for the desired target machines (or some 
of them) already exist, the cost of implementing a set of SHOL translators 
is greatly reduced. (Even if no such translators are available, however 
the cost of implementing the SHOL. through modification of an existing lan- 
guage should be less than that of developing a new language. This is 
because language design should be less difficult and because exi-ting 
knowledge about implementing the language can be employed. ) 

- Quality of existing documentation for the selected base lancraage 
IS another cost factor. In establishing the SHOL as the language used by 
^j.mulator programmers, a significant retraining effort will be required. 
J us will require tutorial and user documentation of excellent quality. 
• -e degre.e to which existing base language documentation can be adapted 
.o 'his purpose has a significant impact on cost. Another consideration 
involving documentation is the availability of a detailed and accurate 
language specification for the chosen base language. Such a document 
facilitates the design (and specification thereof) of the language built on 
that base, thereby reducing language design costs. 
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. In view of these factors, we have considered only language modifi- 
cations satisfying either of the following criteria: 



ThoY are essential to satisfy functional requirements 
of sfgnificant importance in sirrtulator programming, 
e. g. , fixed point arithmetic. These are the require- 
ments asterisked in Section 6. 



b. 



They are relatively easy to provide and are of 
significant benefit, even through not absolutely 
essential to meet simulator needs. 



A language that is modified according to these criteria will ^be optimal in 
the sense that the benefits of the modifications probably outweigh the 
difficulty of making thern. ^ ' 



It is necessary when modifying a language to conform to its exist- 
ing syntactic conventions, i.e. , added features must employ a syntax 
which is compatible and consistent with that of existing features. For 
example, if conditional expressions (e. g. , x = IF condition THEN y 
ELSE z) are added to a language, their syntax should conform to the 
language's existing IF-THEN-ELSE construct as much as possible. 
This would not be at all possible in FORTRAN, which does not have an 
ELSE component in its IF statement. In general,^ the more the base | 
language differs from the desired language, the more difficult it is to ^ 
maintain syntactic integrity. 

When selecting a language for modification then, it is important 
to consider how closely the syntactic conventions of the language corres- 
pond to those considered desirable lor the SHOL. Furthermore, the 
goal oi consistency with existing syntax must play an important part in 
the actual design of the SKOL. 

3 Non-Interierence with Existing Language Fe atures 

A similar goal to that described above is the avoidance of complex 
or undesirable interactions between modifications and existing features. 
As discussed previously, this problem is compounded as the extent of 
modification increases. Deletion of feature ^ conr^idered to be undesirable 
can have a severe impact, since the feature may be needed in the semantic 
definitions of other aspects of the language, perhaps in a manner which is 
not immediately apparent. For example, deletion of a data type can have 
an impact on the implicit conversion algorithrr. employed in the language. 

Additions must also be evaluated with respect to their interactions 
with the rest of the lang\iage. For example, if file I/O is to be added to 
PASCAL, it should be added in a manner consistent with PASCAL'S exist- 
ing I/O capability, which is very low-leveL Perhaps the low-level 
primitives would be used to build the file I/O feature. 
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Additions should not introduce excessive redundancy into the 
language. For example, if a CASE construct is to be added to PL/I i*^ 
might be desirable to eliminate label arrays, which now serve somewhat 
the same purpose. On the other hand, it might be preferable to conclude 
that PL/I's label arrays are adequate for the purpose of simulator 
programming, thus avoiding both the addition and the deletion costs. 

7- 4 Upward Compatibilits' - 

A possible goal in developing the SHOL is upward compatibility 
with the base language. This means that the base language is a prop-' 
subset of the new language, (This, of course, rules out the deletion o' 
features from the base language. ) 

A requirement for upward comcatibilitv increases the difficultv 
(and hence the cost) of modifying the language. It is sometimes quite ' 
complex to extend the language syntax to incorporate desired additions 
without altering syntax of existing constructs, especially if any degree 
of syntactic integrity is to be preserved. As an example of this problem 
consider the difficulty of adding to FORTRAN an IF-THEN-ELSE 
construct which allows groups of statements as objects of the THEN and 
ELSE, and which still accepts such FORTRAN statements as "IS 
(J. LT. 10) Q 3 R+ S ". 

The primary advantages to upward compatibility are that 
programs in the base language will be accepted (and correctly translated^ 
by the translator ol the new language and that programmers trained in 
the base language can convert m.ore re.adily to the new language. These 
advantages, however, are only realizable if there is a significant body of 
existrn;/ code in the base language which is to be reused in systems built 
with !.':e new language and if pro grammer s are already experienced with 
the base language. (Of course, it may be that programmers skilled ir 
the base language would show resistance to the new features, and hence 
take longer to become proficient in the new language than those previously 
uniamihar with the base. ) , • r y 

The major impact of the issue of upward compatibility is on the 
actual task of language modification. In general, it increases costs and 
detracts from the uniformity of the resulting language and should onlv br 
required if significant benefits will be obtained. 
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Section 8 



LANGUAGE EVALUATION AND MODIFICATION SUMMARIES 



Since all c,f the languages would benefit from modifications to 
make them more suitable for simulator programming, in this Section 
we discuss the modifications considered most cor^f. effective. For each 
language, we will cite its major advantages and then discuss the modi- 
fications that are recommended. The modifications have been selected 
based on the analysis in Section 6. In general, modifications needed to 
make a language satisfy essential SHOL requirements are specified. 
Other modifications that are relatively simple to make and that would 
be of significant value are also proposed. 

Each modification is evaluated in terms of its design and 
implementation complexity. Design complexity is increased if the 
modification requires changes to many parts of a language, i, e. , if 
it affects the syntax and/or semantics of a significant proportion of 
constructs in the language. Design complexity is decreased if a 
modification is localized with respect to the capabilities a language 
provides and if the modification does not entail discarding existing 
language features. Implementation complexity is concerned with the 
amount of t-ffort needed to modify or create a compiler that supports 
the modification. The design and implementation complexities are not 
always the same, for reasons that will be noted in discussing the 
modifications. After recommending modifi cations -to all the languages, 
we will summarize the estimated design and Implementation complexities 
of the modifications and discuss which language is best suited for 
modification and subsequent use. 

The dcsig and implementation complexities are evaluated on a 
scale of 1 to 5, with 1 indicating that tl^e modification is simple and 5 
indicati.ng the modification is complex. A modification of the form: 

(3, 5)- add fixed point 

means that the design complexity factor is'3, the implementation com- 
plexity is 5, and the requirement for fixed point was considered 
essential in Section 6. 

FO RTRAN Modifications 

The major advantages of FORTRAN are that it is available on 
inany simulator target machines, many simulator programmers are 
experienced in its use, it is well documented (many tutorial publications 
exist), and it is on the DoD list of approved languages (DoDI 5000. 3 1). 



Its nn.j.:. disadvantages are its lac. of fixed point and record types, its 
lack of c<-.,.trol over data representations and its weak control structures. 

The recommended modifications lO FORTRAN are: 

(1, 3) inc.-ease identifier length 

The current length is inadeauate to provide readable and 
meaningful identifiers. Making identifiers longer is a 
simple language change, but would require reorganization 
of a basic part of a FORTRAN compiler, the symbol table. 

(3, 5)- add fixed point 

Fixed point arithmetic capabilities are complex to design 

and complex to support because of optimization requirements. 

(3, 2)^' add enumeration types 

As new data types are added to FORTRAN, the methods of 
declaring variables gets more awkward, necessitating 
perhaps more design effort than in other languages. The 
implementation of enurnt ration types is relatively straif'hL- 
lorward, however. 

(3, 3)* add character data type and operations 

Th-s should be straightforward in detail, although the number 
of details to be designed rates in complexity as 3. 

(2, 1)=:= unprintable characters in strings 

Deciding how tp do this in a way that is consiste'nt with the 
rest ol the language will require some thought, but its 
implementation should be easy. 

(3, 2)- ability to define new character sets 

■ The design is difficuU (it has not been done except in the DoD 
Common Language designs) but sin'c^e the design decisions 
are localized to one type in the language, we rate it a 3 in 
language complexity. The implementW ion ramifications are 
potentially no more co.nplex than Wdling packed arrays, a 
capability required for other reasons as well. 
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(3, 3)^^ add bitstring type and operations 

We generally rate adding a completely new type and operation 
as complexity lever3. 

(2, 3)-'' add pointer type 

The syntax and usage of pointers can be relatively straight- 
forward to design a? a modification. 

( 1 , 3)'- add dynamic allocation , 

Providing simple dyne.n-dc allocation operators poses no 
difficulties, but the run-time support is more of a complication. 

(4, 3)''' add record data type 

The record type is complex and so we rate it 4. 

(3,3) add constant expressions evaluated at compile time 

Modifying syntactic rules so constant expressions are permitted 
in every context currently permitting literals makes this 
modification more complex than might otherwise be expected. 
The implementation is complex because of the need to simulate 
target machine arithmetic, potentially, or at least to compile or 
interpret expressions being evaluated at compile time. 

(2, 1) correct no/. -uniformities in use of expressions 

I'he constraints on use of expressions as subscript indices can 
be easily removed, improving the uniformity of the language. 

{2,2)-'- add constant names 

This is relatively straightforward. 

{4.3) add automatic storage class 

This is a significant change to F'ORTRAN but is worthwhile in 
simplifying storage allocation problems for what are currently 
treated as temporary common data locations. 

(4,2) permit nested I F - T FIEN - F: LSE statement forms 

This is a significant change to FORTPIAN and requires deleting 
the current FOPvTFlAN form to avoid duplication of capabilities. 



(2,3) add CASE statement"' 

This is a significant change to FORTRAN concepts, since it 
adds the concept of a compound statement to the language, 
but given that the concept is already needed for IF-THEN-ELSE 
statements, the additional effort for a CASE statement is not 
great insofar as the language design goes. 

(2, Z)-'- add conditional expressions 

The semantic rules are straightforward if both^arms of the 
conditional are required to be of the, same ' type^^ e. g. , if IF B 
THEN 3. 0 ELSE 2 is forbidden. . 

(2,2) add conditional compilation 

Given that IF -THEN-ELSE statements are in the language, 
this is not a significant amount of work to add and it is very 
useful for reasons discussed in Section 4. 7. 

\2, 2)'- add indefinite loop iteration 

Adding DO WHILE loops is fairly straightforward. 
(2, 1) ad.H constant parameters 

This is an easy change to the language specification even 
though it is u significant change to the capabilities of FORTRAN, 

\Z,4) add indeyed .^nd direct access files 

Tl. e V e add' s library procedures and, indeed, have been 
made available m v .is \>/ay in some rORTRAN implementations. 

(2, 3)- add parallel processing support 

Simple primitives can be added a5; procedural extensions. 

(3, 3)- permit programmer packing specifications 

The variety of packing specifications required and their use 
throughout the language is complex because of the widespread 
impact on the language. 

(1, 2)- add assembly language and inline subroutines 

This is straightforward once the decision about how to do it 
is "made. 

(3,2)- add facility for sharing common'datapool definitions. 



The FORTRAN COMMON facility is, usable for sharing data 
locations, but a more reliable method of sharing definitions 
similar to JOVIAL COMPOOL facilities would be a worthwhile 
change. 

The recommended modif: rations have an estimated design com- 
plexity of 61 and an estim-\t-d implementation co mplexity of 63. 

PASCAL Modifications 

The major advantage of PASCAL is that it is designed with 
simplicity and reliable programming in mind. The number of PASCAL 
translators is increasing, but they are not wexi controlled, leading to 
t-ranslator-deperident PASCAL dialectd. Very little must be deleted 
from PASCAL to make it acceptable as a SHOL, but many capabilities 
must be added. The most significart PASCAL disadvantages are its 
lack of fixed point arithmetic, its hu:.k of separate compilation facilities 
and Its lack of provision for -.ontrolling data representations. 

Recommended modifications to PASCAL are: 

(1, 1) add a break charictei in identifiers 

Break characters p^-rmi.: more readable identifiers to be used 
in orograms The change i. a simple one to make. 

(1, 1) add M'.X/MIN and trigonometric functions 

Providing these capabilities in a library is straightforward. 

(3,?)^ add fixed p^int (see FORTRAN discussion) 

(1, 1) permit duplicate names for enumeration elements 

This is a relatively simple change requiring that some method 
or resol/ing ambiguitie s be provided. Several language design 
Options are possible. 

(2, 1)- unprintable characters in strings (see FORTRAN) 
(3,2)^ permit new character sets to be defined (see FORTRAN) 
(1, 1)- incor{Sorate a fetring data type ^ 

This iir^jt^s^^ syntactic change, since the representation of such 

type will be fh^^ame as the current string representation, 
namely^ arrays of clTErrac-t^r-s.^ 

(1, 1)^ provide base ?. or base 8 literals 

Tins is a simple syntactic addition. 
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( 1, 1) type-safety of variant records 

PASCAL currently permits tag fields of variant records to be 
assigned directly. This capability is no^ required in simulator 
program^ming. Removing this capability is t^imple. 

(3,3' add constant exoressions ey ^ijated at compile time 
(see FORTRAL; 

(1, 1) add constant records and arra / 

Since PASCAL already supports constant . . '*s, extending the 
capability to records and arrays is straig.. ' --rd. 

(3, 3) add external : ' storage class 

Since PASCAL does t-. + ^pport separate -^-j. -his is 

a significant change. 

(1,1) add initialization o' V.' > oies 

This is a simple langua^<-' :'nge. The i mple men i.ili or-, c om- 
plexity is also straightfoT w;-. .-d. 

(1, 1) add an ELSE alternati.ve in CASE statemenis 

(3,Z) permit ranges in CASE statements 

Permitting ranges in CASE statements v/ill require altering the 
CASE "tatement syntax in a way thai, requires soit-^e thought. 
Adding an ELSE clause is s traightlo rwa r d , hov/ever. 

(2,Z)^^ add ccnd-rional expressions (see FORTRAN) 

(Z,2)=^ add conditional compilation (see FORTRAN) 

(3, perrmf- array parameter subsc^. : ^ts to be non-constant 

T;r:..- Ij a si[;n ficanl change to the language capability. ]is 

int.. ;r^ration with the verA of the language requires careful des\cn. 

(1, 1) define parameter .^la chin^ rules 

This corrects an oversight in the curreni languai:;^. tsj;e. "iration. 

(Z,4)=^ add direct and indexed access fiU s, (see FOR'lPvAM) 

(Z, 3)* add parallel processing support 

Simple primitives can probably be added as procedu 
extensions. 

V: 
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' {3; 3)* permit programmer packing^ specifications (see FORTRAN) 

(1,2)* add .assembly lang-iige and inline subroutines (see 
FORTRAN) 

(4.4) * add facility for sharing con:mon datapcol definitions 

PASCAL currently has no separate compilation capability. 
Designing one for PASCAL and implementing it is therefore 
more complex than :or Lhe other languages. 

The recom,mended mou if i ca ti on s have an estimated design com- 
plexity of 46 and ar im;p]c: mentation complexity of 49. 

J73r iModificat ions 

1 cur?>^^ advantage of J73I is thst it meets most of the essen- 

tial SHOL require n..-nt3 and it is on the DoD hst of HOLs approved for ' 
use in developing new DoD sofUvare. Its ma;or shcrtcoming is the 
,ack of a tixed point data type arid variant records. 

The recommeiiried ni. -dificaticns to j73J are: 

(3.5) * add fixed pr.int (--e FORTRAN; 

(i, 1)* add MAX/MIN and trigonometric fcnctions i^ee PASCAL)' 
(4, 3)* add enumeration ^je a-. o;;.e rations 



This addition is mo-e duficult than for the other ianguag'- ■.; 
because the current status type capability mn,^,. be modif , od 
i.e. , the modifica'.-.on re->uire£ both a deleti n.. and an c.dditi'on 
to the language. 

(3,2)* add Boolean data type and operation,-. 

Adding the Boolean daf.. type - ^1 reauire removinp the f-esent 
method ol computing Bool-;.r, , .-^suJts Jrom the language- 'namely 
tne use of bitstrings co gel ^ae effect of Boolean ooerations) 
Although adding the Booiean type to a language not having it 
woulci be rated a 2 in design complexity, since this change to 
J/3I requires modifying .-.n e: i.tmg capability, we rate the de'sign 
complexity as 3. Implementation ,co.-..,plexity is 2 bf -use ^h.-' 
Boolean operanons are already present in tb- lan^aa;,e; it's 
just the syntactic and sema-tic constraints '^..i must'be changed. 

(3.2) * ability to define new character set (see FORTRAN) 

(3.3) make pointers a distinct data ty;-.; 
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Pointers in J73I are considered integers. This use of integers 
does not contribute to reliable programming. Adding pointers 
as a distinct data type is therefore equivalent to adding a new 
type to the language. 

(1.3) ^^ ad,d dyinamic allocation (see FORTRAN) 

(4.4) permit record variants to be defined ^ 

Adding this capability requires modifying J73I to forbid the use 
of OVERLAYS to obtain record variants and so this change is 
somewhat more complex than simply introducing record variants. 

(4, 1) permit record components of array or record type 

This capability requires a significant redesign of the JOVIAL 
record capabilities, 

evaluation capabilities 
is currently provided except 

(2,2)- add constant name s (see FORTRAN) 

(1,2)- permit assignment of arrays and records as a whole 

J73I already permits such as signments for records that are 
elements of arrays. Extending the capability to complete array.s 
and records is not difficult. 

(3,2)=^ add conditional expressions (see FORTRAN) 

(3, 3) require explicit labeling of CASE alternatives 

Requiring that CASE alternatives be labelled explicitly will 
significantly increase the reliable and understandable use of 
CASE statements. However, it is a more complex change than 
might be fhought, since ranges of labels must be provided as 
well as simple constants. 

(3, 3)^ permit array parameter subscripts to be non-constant 
(see PASCAL) 

(3, 5) - provide an I/O capability 

Even though I/O can be supported by defining procedures, 
deciding what the routines should be and implementing them is 
a significant task. 



(2, 3) expand constant expression 

No constant exipression capability 
for bitsiring c'xpre s sion s . 
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(2, 3)^ add parallel processing support (see FORTRAN) 

(1,2)- add assembly language subroutines and inline routines 
(see FORTRAN) 

The recommended modifications have an estimated design 
complexity of 46; the estimated implementation complexity is 

J3B Modificatio ns 

The major advantage of J3B is that it has already been proved 
suitable for use in applications requiring efficient object code. Also, 
it meets most major SHOL requirements. 

Recommended modifications to J3B are: 

(1, 1) add MAX/MIN and trigonometric functions 

(3,2)* add enumeration-types and operations 

(3,2)* add Boolean data type and operations (see J73I) 

(2> 1)^ unprintable characters in strings (see FORTRAN) 

(3.2) * ability to define new character sets (see FORTRAN) 
(1, 1)- add base 2 and 8 literals 

(1, I)* permit bitstring equality/inequality 

(1.3) * add dynamic storage allocation (see FORTRAN) 

(4.4) * permit record variaT:.ts to be defined (see J73I) 

(4, i)* permit re cord ^ompo.ients of array or record type 
(see J73I) 

(1,2) extend expression eval. ration 

y 

Change the language so relational comparisons (e.g., A = B) 
are considered constant expressions if A and B are constants. 

(1, 1) add constant names for arrays and records 

Since J3B already supports constant names, this is a simple 
modificatior . 

(1.2) * permit assignment of arrays and records (see J73J) 

(3.3) add CASE statement and remove SWITCH 
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This modification will improve the control structure capabilitie 
of the language. 

(2.2) ^ add .conditional expressions (see FORTRAN) 

(3, 3)^ permit non-const;^ " n array parameter s:ibscripts 
(see PASCAL) 

(3,5r" provide an I/O cap:;bj.lity (see J73I) 

(2.3) * add parallel processing support (see FORTR// 
(1, 1)'^ permit specifiable array packing 

(1, 1)^ permit assembly language subroutines 

The recommended modifications have an estimated design com- 
plexity of 41. The estimated implementation complexity is also 
41. 

PL/I Modifications 

The major advantages of PL/I are that it is the most widely 
used of the candidate languages other than FORTRAN, it is well docu- 
mented, and it provides most of the features required. The major 
shortcoming is that PL/I is more complex than is required^ 

Specific recommendations for modifications are: 

(3,2)-'' add enumeration types (see FORTRAN) 

(3,2)* add Boolean data type and operations (see J73I) 

(2, 1)- unprintable',character G in string literals (see FORTRAN) 

'(3,2)^ ability to|define new character sets (see FORTRAN) 

(1, 1)-' add base 8 and 16 bitstring literals (see J3B) 

(1,2) add parameter specification for procedure variables 

Since PL/I permits procedure variables, it is important to 
improve the reliability of this capability by permiuing the types 
of the parameters to be specified. 

■(4, 3) permit record variants to be defined 

Fitting the concept of record variants into PL/I will probably 
require a complete redesign of the PL/I record type, but the 
usefulness of variant records is sufficiently great to make this 
change worthwhile. 

I:,'. 
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(3, 3} add constant expression evaluation (see FORTRAN). 
(2,2)^ add cbnstant names (see FORTRAN) 

(3, 3) add CASE statement and remove label arrays (see J3B) 
(2,2)=5^ add conditional expressions (see FORTRAN) 
(2, 1) add constant parameters (see FORTRAN) 

(3, 3)- permit programmer packing specifications (see FORTRAN) 

(1,2)- add assembly language and inline subroutines (see 
FORTRAN) 

The recommended modifications have an estimated design com- 
plexity of 33 and an estimated implementation complexity of 29. 

Overall Su m m a r y 

The estimated design and implementation complexities for the 
recommended languages are summarized below: 

Language Design Implementation 

FORTRAN 61 63 

PASCAL 46 49 

J73I 46 49 

J3B 41 41 

PL/I 33 Z9 

After the recommended modifications are made, each of the languages 
will be approximately equal in suitability for programming flight simu- 
lators. Since PL/I is the simplest to modify, it is a good choice as a 
base, especially since it was also evaluated as a suitable unmodified 
language. 

Of the two languages approved by DoD for use in implementing 
new systems, namely, J73I and FORTRAN, J73I is clearly more suit- 
able in bdth modified and unmodified form. Mor ^ programmers are 
familiar with PL/I than J73I, however, and there are also more train- 
ing materials for PL/I. On technical grounds'; then, PL/I is the 
optimal choice for modification. However, the choice J73I would^ 
not be unacceptable and would be more likely to be a jepted within t\{e 
Air Force environment. 

In the next^section we discuss implementation considerations 
for a standard simulator HOL based on modifying PL/I. 
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IMPLEMENTATION CONSIDERATIONS AND 
RECOMMENDATIONS 
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The' following subsections discuss various approaches to 
developing a workable SHOL facility to support simulator program- 
ming. Previous sections have justified the selection of PL/I as a 
base and have described the modifications recommended to develop 
the SHGL. 

Self'Hosting vs, C ros s -Compilation 

Flight simulator systems have traditionally been based on a 
variety of different target machines generally commercially- 
available computers of moderate size. It is assumed that this practice 
will continue once the SHOL is in use. It has also been the custom 
to develop all software directly on the intended target machine. That 
is, language processors (assemblers and compilers) run on. the target 
machine itself, and all program debugging is carried out on this 
machine. The main advantages to this approach are: 

• there is no additional hardware cost over that required 
for the actual simulator 

® programs maybe modified (and reassembled or 

recompiled) at field locations where only the target 
machine is available 

Another approach to simulator software developn ent would 
be to use a single large-scale. host,computer for translation and for 
much of program checkout. This computer would have cross-compilers 
and debugging support tools for the various target machines. There 
are many advantages to this approach, including: 

© the greater power of the host computer ccn be used to 
advantage in the translation and support programs 

» much of the code in the cross-compilers can be 
reused in the various target machines 

• more sophisticated debugging support can be provided 

• more powerful facilities for editing, file maintenance, 
time- sharing, etc. are available for program 
development ' 



hese advantages, of course, must be weighed against the 
disadvantages of the -idded cost of the host computer and its 
unavailability for onsite modification. 



'.The decision made with respect to self-hosted compiling 
vs. cross-compiling will have considerable interaction with other 
cispects of SHOL development, which will be discussed in later 
subsections. It is recommended that the c ros s - compilation approach 
be adopted for the SHOL. The language to.be implemented is sufficiently 
complex that a more powerful computer is desired to support trans- 
lation. This will allow development of a more sophisticated translator 
which can produce superior object code (in terms of space and time 
efficiency) to that produced by a translator operating on a small 
machine. This is an important advantage since efficiency is vital 
in this application area. 

Another major reason for c ros s - compilation is the decreased 
cost of translator development. Compilers for each of the desired 
targets can share the same machine -independent portions (front ends) 
and will require only the development of new code generators. Code 
generator development is significantly less costly than total compiler 
development. As will be discussed later, this approach also facilitates 
language standardization by increasing the likelihood that all translators 
accept the same langi age. 

A major concern with this approach is the initial cos' of the 
host computer and of development of the fir^t cross-compiler. 
Customarily simul itor purchasers have not had to pay for separate 
development comp -ters or for the production of language translators. 
It would not be reasonable to assume that the first purchaser of a 
simulator written in tne SHOL should bear all of these initial costs. 
Ii the rev-ommended c ros s -compilation approach is to be adopted, it 
will probably be necessary for simulator developers to obtain some 
^spacific support for the creation of a SHOL facility. Another problem 
is that onsite simulator modification cannot be readily supported 
except through appropriate time-sharing interaction with :he host 
facility. Beth of these problems are significant, but the current tread 
of DoD thinking, as refl'-cted in the common language effort, is to 
provide such centralized support to DoD programming efforts. 
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Language Development 

We have recommended that the SHOL be developed. by 
modifying the PL/I language. Modifying an existing language leads 
, to a simpler design effort than, developing a new language. Reasons 
for this include; 

® Most needed features are already avai-able in the 
base language and need not be designed explicitly. 

o Syntactic and semantic definitions of features already 

in the language are available, and are (hopefully) free 
of undesirable interactions, 

• Existing language - defining documents can be expanded 

to define the new 'anguage. 

Implementation of such a language is also simpler than implementing 
a new language, as discussed in. the next subsection. 

The modifications to PL/I which have been recommended were 
discussed 'n Section 8. All the modifications specify additions to 'PL/L 
This indicates t^^at design of a SHOL which is upward-compatible with 
PL/I might be reasonable to attempt, though it is not clear whether 
this is a worthwhile goal. The usual motivation for upward- compat^bili t 
IS the reuse of existing code in the base language. As there is probably 
little or no existing simulator code in PL/i; this. would not be a 
significant concern. 

However, it may be desirable to develop a SHOL wnich is 
upward-compatible with PL/I for reasons of economy. As discussed 
in Section 7, the cost of development increases when features are 
deleted or when their syntax is altered, as weM as when they are added. 
Thus it is probably most cos t -effective to leave existing PL/I features 
as they are. This is particularly true if use can be made of existing 
PL/I translator code in developing the new translator. 

If :-• more extensive language design effort is to be undertaken, 
a language satisfying more of the SHOL requirements can bp developer]. 
Many of the features of such a SHOL require significant chan/.^'c; to 
tiie basic syntactic and semantic conventions of the PL/I languaee 
(e.g. , strong typing), and incorporation of such features into PL/I 
woul ] not be practical. PL/I also contains many features which are 
supernuous for the SHOL. If a language exactly meeting the stated 
requirements were to be developed, it would probably be preferable 
tc design an entirely nevy language rather than attempting such drastic 
modification to PL/I. Such an approach has not been recommended, 
however, because it is very costly and so is not an optimal way of 
providing a useful SHOL. 
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Translator Development 

The recommended approach to SHOL development requires 
adding features to PL/I. This indicates modifying an existing 
translator is a possible approach. Factors influencing 'this decision 
include: 

« whether PL/I compilers for the desired host and/or 
target computers are available 

o whether -the language to be implemented requires 
relatively few changes to the base 

• whether the compiler considered for modification 

is well-documented and is implemented in an appropriate 
language in a readable and modifiable manner. 

We have recommended that SHOL translators execute on a 
single large-scale hd^t machine. This requiri^s that the part of the 
compiler which is independent of the target machine* be 'irapl.emented 
only once, while machine -dependent portions (code generators) will 
be developed for each target computer. ^This is a more cost effective 
approach to the development of a set of SKOL translators for all 
inte^nded targets than is the development of a self-hosted compiler 
for each target. Furthermore, it allows programming of the compiler 
in any language available on the host computer rather than requiring 
implementation in assembly language or FORTRAN, which are likely 
to be the only choi'ces available on most simulator target machines. 
If a host is selected which already has a compiler for the base language 
(PL/I),, the SHOL compiler can be implemented in the base language. 
(If the SHOL is designed to be upward compatible with PL/I, the 
compiler would then effectively be written in the SHOL, and could 
compile itself. ) 

Thus, if the compiler, is ultimately to be written in the SHOL 
itself and/or if it is deemed worthwhile to make use of existing 
translator code, it would be desirable to seriously consider selecting 
a host facility which al ready has a PL/I compiler (generating code for 
the host machine). It is unlikely that the selected host would have 
PL/I cross-compilers already available for any simulator target 
computers, but existing compilers could be used for SHOL compiler 
implementation and existing compiler frontend code could be adapted 
to the various cross-compilers. ' 

An implem'entation method which might also be considered 
is to use a preprocessor that would translate programs written in 
the SHOL into the base language. These programs could then be 
compiled using. a compiler for the base language. However, this 
approach is most valuable if compilers for the intended targets already 
exist for the base language. Thus it might be reasonable if FORTRAN - 
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were the selected base, but it is probably not for PL/L (Of 
course, the large number of modifications which would be necessary 
to extend FORTRAN to a SHOL make the use of a preprocessor 
unreasonable. ) ^ . 

Another consideration in developing a SHOL facility is the 
possible initial implementation of a "quick and dirty" SHOL translator 
to use in testing the feasibility of the language for simulator program- 
ming. Such a translator would translate and execute SHOL programs 
for test purposes only. This might b.e of some use in determining 
whether the language includes the constructs necessary for the 
programming of simulators. However, it would not test the single 
most important requirement of the SHOL translator whether it 
generates object code jyhich is efficient enough for the application. It 
is likely that a SHOL based on the suggestions in this report will meet 
the functional requirements of simulator programming, and basing 
the SHOL on a widely-used language such as PL/I should guarantee 
its overall usability, so the test translator approach is probably not 
justified. 

y 

SHOL Programming Support ' 

In- addition to a language translator for the SHOL, certain 
support tools are necessary to facilitate the development of simulator 
systems. These tools generally aid in the integration of individual 
simulator programs into a total system, and in the debugging and 
validation of individual programs and of total systems. Section 5.5 
discusses some such tools currently in use at Singer-Link. 

. Support programs may be divided into those which opejrate on the 
the program development (host) facility and those which operate on 
the actual- simulator (target) facility, (Even if the same machine is 
used for both, such a conceptual division is reasonable. ) It is intended 
that'"the SHOL be usable for the programming of all target-based 
support tools as well as for the programming of the simulator 
application programs. 

Support tools which operate on the host machine should be 
considered part of the overall SHOL facility. In some cases, they 
may be incorporated in the SHOL translators, though they are not 
properly considered part of the la^nguage itself. Tools which might be 
developed as components of the SHOL facility include: 

• ^. editors 

• program statistics collectors (q. g. , instruction usage 
counts, time estimates for designated intervals) 

• documentation aids 
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set/used file capabilities 



• liak editors (for creation of target machine load 
modules) 

• program maintenance tools , 

• application libraries 

( 

• program optimizers 

• target machine simulators 

Target machine instructi'on-level simulators are a particularly valuable 
program checkout tool made possible by the use of a separate host 
computer. Many debugging features which are difficult to provide on the 
actual target computer can be implemented easily in a target machine 
simulator. Examples of features such a simulator can provide are: 

• mnemonic tracing 

• interval timing 

• interrupt modelling 

• display of values of specified variables at specified 
time or location in the program 

• trapping at a specified time or location 

• setting of values of specified variables 

o loading of test data sets ^'Sh> 

Debugging tools should encourage debugging in terms of symbolic 
program entities rather than machine values and addresses. 
Variables to be set or .displayed should be referenced by name rather 
than by machine address, and values should be entered or displayed 
in units apj^ropriate to the variable, rather than in octal or hexadecir .al 
form. Recognizing that machine-level debugging is sometimes 
necessary, however, some support for this should be included. 

Though some of the host-based support tools will differ from 
one target machine to another (e.g., mr^ ?hine simulatorSp link editors), 
user interfaces to the tools should be corvsistent. This is dictated by 
the goal of creating a unified SHQL development facility , rathe tham 
a miscellaneous collection of support programs. 
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Language Standardization 



One of the major reasons for the development of a SHOL is 
the desire for program portability. As discussed in Section 4, 7 
there is particularly high potential for program portability in the 
simulator application area* Though there are some difficulties in 
attaining this goal (also dr scussed in Section 4* 7), it can only be 
approached if the SHOL is standardized. That is, all SHOL translators 
(i.e. , foi- all target machines; must accept the same inputs and must 
produce equivalent results for identical inputs. 

Complete language standardization is difficult to achieve. The 
major prerequisite fpr language standardization is a complete and 
rigorous language specification document. vAri appropriate syntactic 
definition can be developed fairly straightforwardly, but, as indicated, 
full semantic specification is difficult. Stand'ardization of the SHOL 
will be facilitated by selecting a base language with good defining 
documentation, and by limiting modification to that language. As 
mentioned earlier, use of cross-compilers with the same machine- 
independent part (front end) guarantees syntactic equivalence. 

If language standardization is to be useful, it must be possible 
to validate that translators do in fact conform to syntactic and 
semantic specifications. This requires development of a rigorous set 
of acceptance programs to be used with all translators. The tests 
must not only ensure that programs compile without syntactic errors, 
but also that their semantics is as specified. This set of tests must 
be developed as a part of, the SHOL design and specification effort. 

Establishing SHOL Usage 

Clearly there is little to be gained by developing a SHOL facility 
unless it will then be used. Also, though it will decrease development 
and maintenance costs on any single effort for which it Vj used, the 
full benefits of the SHOL will only be realized if it is used in all 
simulator programming. Only then will program reuse be a . ^ 
possibility, and only then will programmers become skilled in the 
use of the language. 

While it is possible to guarantee use of the SHOL by simply 
requiring its use when procuring simulators, it is desirable to back 
up this requirement by making the SHOL facility a sufficiently attractive 
alternative that programmers will prefer t-^ vi5^e it. Once programmers 
become- conversant with the language, the increased ease of program- 
ming in the SHOL should be adequate motivation for its continued use. 
Initially, however, other factors will encourage the transition. These 
include: 

• • superior program development and debugging tools 

m application/library programs available through the 
SHOL* facility ^- , 
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» high-qr mentation oriented to programmer 

backgrou.'. 

• . well -planned ing effort 

The importance of trair.ing and of user documentation in 
easing the transition to SHO.L usage cannot be overemphasized, 
particularly in view of the 1 rge number of programmers involved. 
In addition/to acquainting pL ^'rammers with the use of the facility, 
a serious training effort a'^ v res them of management commitment 
to the changeover. 

All tutorial material for the SHOL should-include numerous 
examples illustrating how common^imulator functions can be 
programmed invthe SHOL'. This will not only make SHOL usage 
easier to learn; it will also discourage excessive dependence on the 
assembly language subroutine capability, (It may be necessary, at 
least initially, to attempt to limit the use of this feature to functions 
for which it is .really required. Section 5.7 discusses these 
requirements.) 

Relation to the DoD Common Language Effort 

The DoD is currently conducting an effort which will result 
in a Common Language to be used for tlie programming of embedded 
computer systems, including flight simulator systems. The 
IRONMAN specification defines the functional requirements to 
be met by the Common Language. Tne IRONA^AN satisfies most 
of the essential SHOL requirements. The significant discrepancies 
between the IRONMAN and SHOL requirements are: 

• IRONMAN does not require conditional expressions. 

• IRONMAN does not require procedure variables and 
arrays. 

• A non-exact fixed point representation is preferred 
to the exact representation required by IRONMAN. 

• ^IRONMAN requires garbage collection of dynamically 

allocated storage, which adds, unacceptable overhead. 
Explicit allocation and deallocation are desired, aTid 
would have to be supported by extension to the 
IRONMAN language. 



IRONMAN does not require multiple fixed point 
precisions (which allow space-accuracy trade-offs ). 

IRONMAN does not restrict assembly language use 
to subroutines. ' ' 

IRONMAN I/O and parallel proces sing features may not 
provide the required functions. 

IRONMAN extensibility and encapsulation features are 
considered unnecessarily complex for simulator needs. 



A language satisfying the IRONMAN, however, v/illNprobably be usable for 
programming most simulator functions and will satisfy more (^the SHOL 
requirements than any of the modified candidate languages consi^dered in 
this study. Furthermore, the .DoD backing should ensure the development 
of tlie^ support facilities and training efforts recommended for a smooth 
transition to the SHOL in previous sections of this report. 

As of May 1978, work on two Common Language designs was in 
progress. Some modifications to the July 1977 IRONMAN were being 
made, based on the results of four preliminary^design efforts completed 
in February 1978. Although final designs -are scheduled for test and 
evaluation beginning in April 1979, it is currently unclear how suitable 
these designs will be for embedded cornputer system programming. 
Assuming that further redesign wdll be needed, it is unlikely that 
production compilers for flight simulator computers will be ready for 
use in less than 5 years. 
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SUMMARY. AND CONCLUSIONS 

The main objective of this study was to define hjgher order language 
requirements for programming flight training simulators. A subsidia'ry 
objective was to develop a general approach for determining HOL require- 
ments in a given application area and then to apply this approach to the 
simulator area. The approach we devised analyzes three sources of lan- 
guage requirements--the programming environment, the functions to be^ 
programmed, and langJaage design principles. Requirements pertaining 
specifically to flight simulators^Avere determined by analyzing a variety of 
simulators developed by the Link Division of the Singer Company. Using 
this information, we developed. a generic, model of the prograTnming tasks 
relevant to simulator development. A detailed analysis of language require- 
ments was keyed to this model. 

\ ' . • , ' ' 

Based on this analysis, we prepared a detailed specification of, 
simulator HOL requirements, using the requirements structure of the 
IRONMAN (a specification of HOL requirements for a common DoD program 
ming language). We then analyzed PL/I, FORTRAN, JOVIAL J3B, JOVIAL 
J73I, and PASCAL to see how well each satisfied the simulator HOL reqmre 
ments we had developed. Our analysis showed that PL/I and JOVIAL J3B, 
were best suited for simulator programrri'ing, although only FORTRAN 
was clearly the least suitable language. ♦ f 

Since all the languages failed to' satisfy some of the simulator 
language requirements, we considered what language modifications wou^^'^ 
make them significantly more useful as simulator programming languages. 
Our analysis of the difficulty of modifying, each language indicated that 
PL/I was the most easily modified, and re conruTQ ended modifications were 
described. , . 
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Appendix A 
'..-SIMULATOR MODEL 

This Appendix describes the various' programming tasks pertaining 
to flight simulators. The tasks to be performed and their relationships 
are.described using SADT notation .[Ross, 1977]. An index to the model is 
presented in the following pages. In this index, the notation A331, for 
example, represents a task composed of the tasks A331 1, .A3312, and A3313. 
A page number is indicated for those tasks that are decomposed into more 
detailed tasks. THe' number indicates the page on which the decomposition 
will be found. . 
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Appendix A 



^ ■ ' SIMULATOR MODEL 

Section 

AO ^Simulate an Aircraft' 
Al Build Simulator 

All Create System Data Base'^ 
A 12 Code Modules 
A 13 Compile Modules 
A 14 - Link Modules 
Al' Test Simulator ■ y . 
A21 Test Executive 
,. A22 Test Simulation Programs 
A23 Test Wliol? Simulaitor 
A3 Simulate 

A31 Monitor Execution 

A3 11 Control Initialization 
A312 



Page 
1'96 

197 



198 



199 
200 

201 



Cycle Through ;SimuIat6r. Tasks- 
A3 121 Select 'Frame 
A3 122 Select Cbckpit 

A3 123 Schedule Tasks for Frame Cockpit 

A3 124 Sum Task Times for Frame 

A312'5 ^Sum Frame Times for Cycle' 

A3 13 Compute Spare Time for Cycle 

A32 Initialize Data Base 

A33 Model Aircraft Functions 

A 331 Model Flight 

A3311 Model Aircraft Flight Controls 

A3312 • Model Aerodynamics 

A3312r Process Atmospheric Data 

A33 122 Compute Weight &c Balance 

A33 123 Compute Aerodynamic Coefficients 

A33124 Confipute Ground Reactions 

A33125^ Compute Equations of Motion 

A3313 Model Accessory Systems 205 

r A33131 Model Fuel System 

A33 132 :. Model Electrical System 206 

A33 1321 Compute Electrical 
System Power 

A33 1322 Compute Bus Loads 



202 
203 

204 



Section 



Page 

A33133 Model Hydraulic System 207 

A331331 Compute Hydraulic 
Flow & Pressure 

A331332 Model Secondary 
, ^ Hydraulic Controls 

A331333 Model Landing Gear 

A33134 Model Engine System 

A33135 Model Miscellaneous 

Accessories 208 

A331351 Model Engine Fire 
& Overheat System 

A331352 Model Ice/De-ice 
System 

A331353 Model Canopy & 

Ejection Seat System 

A331354 Model Oxygen System 

A332 Model Navigation & Communications 209 

A3321 Model Communications 

A3322 Model Navigation Equipment 

A3323 Model Navigation Radios 2l0 
A33231 Model Compasses 
A33232 Model Attitude System 
A33233 Model Radio Stations 
A3324 Look Up Radio Station 
A333 Model Motion 

A334 Model Tactics 211 
A3341 Model Airborne Radar 
A3342 Model Armaments 
A3343 Model Electronic Warfare 
A3344 Model Weapon Delivery 
A3345 Model Tactical Environment 
A3346 Model Avionic Displays 
A335 Model Visual 2l2 
A3351 Process Flight Data 2l3 

A33511 Compute Attitude. 

A33512 Compute Position & Velocity 
A3352 Drive Gantry. • 2l4 

A33521 Process Gantry Feedback 

A33522 Control Gantry 
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Section Page 

A3353 Drive Probe 2l5 
A33531 Compute Altitude Limits 
A33532 Control Probe 

A3354 Produce Visual Image 2l6 

A33541 Process Instructor & 
Student Controls 

A33542 Determine Image Focusing 

A33543 Produce Cultural Lighting 

A33544 Produce Visibility Effects . 

A34 Do I/O to Simulated Cockpit 

A35 Communicate with Instructor 2l7 
A351 ' Record/Playback Mission 
A3 52 Set Initial Conditions 
A353 Set Malfunctions 
^ A354 Display/Update Datapool Values 
A355 Display Terrain Mapy 
A356 Plot Aircraft Position and Track 
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